Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

Post reply on HN
Print view View original

271–280 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#271

Post by zahlman »

whywhywhywhy wrote: post #240
oblio wrote: post #173

Earlier quoted context omitted.

There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python. How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

The only word in the `source .venv/bin/activate` command that isn't a complete red flag that this was the wrong approach is probably bin. Everything else is so obviously wrong. source - why are we using an OS level command to activate a programming language's environment .venv - why is this hidden anyway, doesn't that just make it more confusing for people coming to the language activate - why is this the most generi…

> why are we using an OS level command to activate a programming language's environment

Because "activating an environment" means setting environment variables in the parent process (the shell that you use to run the command), which is otherwise impossible on Linux (see for example https://stackoverflow.com/questions/6943208).

> why is this hidden anyway, doesn't that just make it more confusing for people coming to the language

It doesn't have to be. You can call it anything you want, hidden or not, and you can put it anywhere in the filesystem. It so happens that many people adopted this convention because they liked having the venv in that location and hidden; and uv gives such venvs special handling (discovering and using them by default).

> why is this the most generic name possible as if no other element in a system might need to be called the activate command over something as far down the chain as a python environment

Because the entire point is that, when you need to activate the environment, the folder in question is not on the path (the purpose of the script is to put it on the path!).

If activating virtual environments shadows e.g. /usr/bin/activate on your system (because the added path will be earlier in $PATH), you can still access that with a full absolute path; or you can forgo activation and do things like `.venv/bin/python -m foo`, `.venv/bin/my-program-wrapper`, etc.

> Feels dirty every time I've had to type it out

I use this:

  $ type activate-local 
  activate-local is aliased to `source .local/.venv/bin/activate'
Notice that, again, you don't have to put it at .venv . I use a .local folder to store notes that I don't want to publish in my repo nor mention in my project's .gitignore; it in turn has

  $ cat .local/.gitignore 
  # Anything found in this subdirectory will be ignored by Git.
  # This is a convenient place to put unversioned files relevant to your
  # working copy, without leaving any trace in the commit history.
  *
> and I see people paid at a senior level not understand this command.

If you know anyone who's hiring....

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#276

Post by collinmanderson »

zmmmmm wrote: post #260

> Instead of > > source .venv/bin/activate > python myscript.py > > you can just do > > > uv run myscript > This is by far the biggest turn off for me. The whole point of an environment manager is set the environment so that the commands I run work. They need to run natively how they are supposed to when the environment is set, not put through a translation layer. Side rant: yes I get triggered whenever someone tells…

> The whole point of an environment manager is set the environment so that the commands I run work. They need to run natively how they are supposed to when the environment is set, not put through a translation layer.

The `uv run` command is an optional shortcut for avoiding needing to activate the virtual environment. I personally don't like the whole "needing to activate an environment" before I can run commands "natively", so I like `uv run`. (Actually for the last 10 years I've had my `./manage.py` auto-set up the virtual environment for me.)

The `uv add` / `uv lock` / `uv sync` commands are still useful without `uv run`.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#277

Post by RobertoG »

caconym_ wrote: post #227
hardwaregeek wrote: post #149

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.

pfff... "other people projects".. I was not even able to run my own projects until I started using Conda.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#278

Post by rieogoigr »

hollow-moe wrote: post #15

curl|sh and iwr|iex chills my spine, no one should recommend these methods of installation in 2025. I'm against closed computers but I'm also against reckless install. Even without the security concerns these way of installation tends to put files in a whole random places making it hard to manage and cleanup.

for real. You want to pipe a random URL to my bash interpreter to install?

no. thats how you get malware. Make a package. Add it to a distro. then we will talk.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#279

Post by rieogoigr »

mystifyingpoi wrote: post #48
hollow-moe wrote: post #15

curl|sh and iwr|iex chills my spine, no one should recommend these methods of installation in 2025. I'm against closed computers but I'm also against reckless install. Even without the security concerns these way of installation tends to put files in a whole random places making it hard to manage and cleanup.

While I do share the sentiment, I firmly believe that for opensource, no one should require the author to distribute their software, or even ask them to provide os-specific installation methods. They wrote it for free, use it or don't. They provide a handy install script - don't like it? sure, grab the source and build it yourself. Oops, you don't know what the software does? Gotta read every line of it, right? Maybe…

Part of writing software involves writing a way to deploy that software to a computer. Piping a web URL to a bash interpreter is not good enough. if that's the best installer you can do the rest of your code is probably trash.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#280

Post by renewiltord »

d4mi3n wrote: post #42
LeoPanthera wrote: post #18

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ "modules", "here" ] # /// The script now works like a standalone executable, and uv will magically install and use the specified modules.

If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent. This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this i…

[flagged]
Post reply on HN