Comment by zahlman | Hacker News Reader

Comment by zahlman | Hacker News Reader

Parent Full thread

> how much I prefer prepending "uv" to everything instead of activating environments

You can also prepend the path to the virtual environment's bin/ (or Scripts/ on Windows). Literally all that "activating an environment" does is to manipulate a few environment variables. Generally, it puts the aforementioned directory on the path, sets $VIRTUAL_ENV to the venv root, configures the prompt (on my system that means modifying $PS1) as a reminder, and sets up whatever's necessary to undo the changes (on my system that means defining a "deactivate" function; others may have a separate explicit script for that).

I personally don't like the automatic detection of venvs, or the pressure to put them in a specific place relative to the project root.

> I also like how you can manage Python versions very easily with it.

I still don't understand why people value this so highly, but so it goes.

> the inevitable bi-yearly "debug a Python environment day"

If you're getting this because you have venvs based off the system Python and you upgrade the system Python, then no, uv can't do anything about that. Venvs aren't really designed to be relocated or to have their underlying Python modified. But uv will make it much faster to re-create the environment, and most likely that will be the practical solution for you.

Yup. I never even use activate, even though that's what you find in docs all over the place. Something about modifying my environment rubs me the wrong way. I just call ``./venv/bin/python driver.py`` (or ``./venv/bin/driver`` if you install it as a script) which is fairly self-evident, doesn't mess with your environment, and you can call into as many virtualenvs as you need to independently from one another.

``uv`` accomplishes the same thing, but it is another dependency you need to install. In some envs it's nice that you can do everything with the built-in Python tooling.

And when you control the installation, you can install multiple python versions with `make altinstall` into the same prefix, so you don't even need to pass 'project/bin/python, you can just call 'python-project' or 'project.py' or however you like.

Yep. (Although I installed into a hierarchy within /opt, and put symlinks to the binaries in /usr/local/bin. Annoyingly, I have to specify the paths to the actual executables when making venvs, so I have a little wrapper for that as well....)

I agree, once I learned (early in my programming journey) what the PATH is as a concept, I have never had an environment problem.

However, I also think many people, even many programmers, basically consider such external state "too confusing" and also don't know how they'd debug such a thing. Which I think is a shame since once you see that it's pretty simple it becomes a tool you can use everywhere. But given that people DON'T want to debug such, I can understand them liking a tool like uv.

I do think automatic compiler/interpreter version management is a pretty killer feature though, that's really annoying otherwise typically afaict, mostly because to get non-system wide installs typically seems to require compiling yourself.

>> I also like how you can manage Python versions very easily with it. > > I still don't understand why people value this so highly, but so it goes.

Well I do need some way to install multiple python versions in parallel, and ideally the correct python version would be used in each project automatically. I used to use pyenv for this, which puts shims in your path so that it can determine which python executable to run on the fly, but I found that it was sometimes very slow, and it didn’t work seamlessly with other tools. Specifically pipenv seemed to ignore it, so I’d have to use a workaround to point pipenv to the path to the pyenv-installed python executable.

When one tool does both python installs and dependency/venv management, then it can make these work seamlessly together, and I don’t need to screw up my path to make the version selection work either.

I would very much like to know the reason why they named it bin/ here and Scripts/ there. To get some closure.

Annoys me to no end as well. I don't have an answer for you, but I would like one too.

Because bin/ is a conventional name that Linux inherited from UNIX going back literally decades; but there is nothing analogous in the Windows ecosystem, while Windows has a culture of trying to give folders names that are convenient for (and understandable to) end users with none of that UNIX cultural exposure. "bin" means absolutely nothing to the average person who grew up using Windows and is now learning to program with Python. "Scripts" is at least potentially understandable.

There's nothing analogous in Windows to ~/.ssh and yet I can find my keys there even on Windows. There's nothing analogous to /etc on Windows and yet I can find a dns resolver file in \Windows\System32\drivers\etc\hosts

I grew up using Windows and decision to name a folder Scripts (inconsistently), in a multiplatform open source software development project is incomprehensible to me.

If you have multiple python applications with different versions, it's nice to use the same version as deployed.

At least major and minor, patch is rarely needed for python.

Reply on news.ycombinator.com