7 ms·

I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats y

I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats your boat. I also like how you can manage Python versions very easily with it. Everything feels very "batteries-included" and yet local to the project. I still haven't used it long enough to tell whether it avoids the inevitable bi-yearly "debug a Python environment day" but it's shown enough promise to adopt it as a standard in all my new projects.

bobsomers 1y ago
Personally, I prefer prepending `uv` to my commands because they're more stateless that way. I don't need to remember which terminal my environment is sourced in, and when copying and pasting commands to people I don't need to worry about what state their terminal is it. It just works.
zahlman 1y ago
> 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.
- lelandbatey 1y ago
  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.
- biimugan 1y ago
  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.
  - 1718627440 1y ago
    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.
    - zahlman 1y ago
      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....)
- 1y ago
j45 1y ago
This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.
- oblio 1y ago
  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 :-)))
  - roflyear 1y ago
    what happens when you have two projects using different versions of node, etc? isn't that a massive headache? not that it's great to start with, but it does happen, no?
    - oblio 1y ago
      The rest of the world handles that through PATH/PATH equivalent. Either the package manager is invoked with a different PATH (one that contains the desired Node/Java/whatever version as a higher priority item than any other version on the system). Or the package manager itself has some way to figure that out through its config file. Or there is a package manager launch tool, just like pyenv or whatever, which does that for you. In practice it's not that a big of a deal, even for Maven, a tool created 21 years ago. As the average software dev you figure that stuff out a few weeks into using the tool, maybe you get burnt a few times early on for misconfiguring it and then you're on autopilot for the rest of your career. Wait till you hear about Java's CLASSPATH and the idea of having a SINGLE, UNIFIED package dependency repo on your system, with no need for per-project dependency repos (node_modules), symlinks, or all of that stupidity. CLASSPATH was introduced by Java in 1996, I think, and popularized for Java dependency management in 2004.
      - 1718627440 1y ago
        Well, that is how Python does it as well, an venv is a script setting the PYTHONPATH.
sirfz 1y ago
I use mise with uv to automatically activate a project's venv but prefixing is still useful sometimes since it would trigger a sync in case you forgot to do it.
globular-toast 1y ago
One of the key tenets of uv is virtualenvs should be disposable. So barring any bugs with uv there should never be any debugging environments. Worst case just delete .venv and continue as normal.
- nickelpro 1y ago
  This is a key tenets of venvs generally, uv didn't invent anything, it simply brought them under one roof and improved perf.
  - globular-toast 1y ago
    It should have been, but people definitely kept their venvs as pets or, worse, just used the global env.
    - nickelpro 1y ago
      Sure, but you can have pet venvs with uv too. These are tools, if you choose to hold them wrong no one can stop you. uv didn't invent the screw driver or the knife, its novelty is as a Swiss Army Knife which put them all in one.
    - kristjansson 1y ago
      It was way too easy for the venv to be the only artifact of the process used to produce it. pip install, hit a bug, install some other dep, another bug, oh this one needs to be downgraded, and so on until it works. Without more effort to memorialize / remember the steps, deleting the venv destroyed the work to create it. uv, in addition to its raw speed, is very clever to record things in pyproject as the user interacts with it.

bobsomers 1y ago

Personally, I prefer prepending `uv` to my commands because they're more stateless that way. I don't need to remember which terminal my environment is sourced in, and when copying and pasting commands to people I don't need to worry about what state their terminal is it. It just works.

zahlman 1y ago

> 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.

lelandbatey 1y ago
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.
biimugan 1y ago
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.
- 1718627440 1y ago
  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.
  - zahlman 1y ago
    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....)
1y ago

j45 1y ago

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

oblio 1y ago
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 :-)))
- roflyear 1y ago
  what happens when you have two projects using different versions of node, etc? isn't that a massive headache? not that it's great to start with, but it does happen, no?
  - oblio 1y ago
    The rest of the world handles that through PATH/PATH equivalent. Either the package manager is invoked with a different PATH (one that contains the desired Node/Java/whatever version as a higher priority item than any other version on the system). Or the package manager itself has some way to figure that out through its config file. Or there is a package manager launch tool, just like pyenv or whatever, which does that for you. In practice it's not that a big of a deal, even for Maven, a tool created 21 years ago. As the average software dev you figure that stuff out a few weeks into using the tool, maybe you get burnt a few times early on for misconfiguring it and then you're on autopilot for the rest of your career. Wait till you hear about Java's CLASSPATH and the idea of having a SINGLE, UNIFIED package dependency repo on your system, with no need for per-project dependency repos (node_modules), symlinks, or all of that stupidity. CLASSPATH was introduced by Java in 1996, I think, and popularized for Java dependency management in 2004.
    - 1718627440 1y ago
      Well, that is how Python does it as well, an venv is a script setting the PYTHONPATH.

sirfz 1y ago

I use mise with uv to automatically activate a project's venv but prefixing is still useful sometimes since it would trigger a sync in case you forgot to do it.

globular-toast 1y ago

One of the key tenets of uv is virtualenvs should be disposable. So barring any bugs with uv there should never be any debugging environments. Worst case just delete .venv and continue as normal.

nickelpro 1y ago
This is a key tenets of venvs generally, uv didn't invent anything, it simply brought them under one roof and improved perf.
- globular-toast 1y ago
  It should have been, but people definitely kept their venvs as pets or, worse, just used the global env.
  - nickelpro 1y ago
    Sure, but you can have pet venvs with uv too. These are tools, if you choose to hold them wrong no one can stop you. uv didn't invent the screw driver or the knife, its novelty is as a Swiss Army Knife which put them all in one.
  - kristjansson 1y ago
    It was way too easy for the venv to be the only artifact of the process used to produce it. pip install, hit a bug, install some other dep, another bug, oh this one needs to be downgraded, and so on until it works. Without more effort to memorialize / remember the steps, deleting the venv destroyed the work to create it. uv, in addition to its raw speed, is very clever to record things in pyproject as the user interacts with it.