6 ms·

I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It hand

I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv. I've used 'em all, pip + virtualenv, conda (and all its variants), Poetry, PDM (my personal favorite before switching to uv). Uv handles everything I need in a way that makes it so I don't have to reach for other tools, or really even think about what uv is doing. It just works, and it works great. I even use it for small scripts. You can run "uv init --script <script_name.py>" and then "uv add package1 package2 package3 --script <script_name.py>". This adds an oddly formatted comment to the top of the script and instructs uv which packages to install when you run it. The first time you run "uv run <script_name.py>," uv installs everything you need and executes the script. Subsequent executions use the cached dependencies so it starts immediately. If you're going to ask me to pitch you on why it's better than your current preference, I'm not going to do that. Uv is very easy to install & test, I really recommend giving it a try on your next script or pet project!

midhun1234 2y ago
Can confirm this is all true. I used to be the "why should I switch" guy. The productivity improvement from not context switching while pip installs a requirements file is completely worth it.
baby_souffle 2y ago
I didn't know that UV would now edit the script for you. That is just icing on the cake! For the curious, the format is codified here: https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/
scribu 2y ago
The install speed alone makes it worthwhile for me. It went from minutes to seconds.
- BoorishBears 2y ago
  I was working on a Raspberry Pi at a hackathon, and pip install was eating several minutes at a time. Tried uv for the first time and it was down to seconds.
  - guappa 2y ago
    Why would you be redoing your venv more than once?
    - dagw 2y ago
      Once rebuilding your venv takes negligible time, it opens up for all kinds of new ways to develop. For example I now always run my tests in a clean environment, just to make sure I haven't added anything that only happens to work in my dev venv.
      - kstrauser 2y ago
        That's smart. Oh, you used `pip install` to fix a missing import, but forgot to add it to pyproject.toml? You'll find out quickly.
      - guappa 2y ago
        I thought you wanted to test your program, but seems you want to make sure that your unzip library keeps working :D
    - BoorishBears 2y ago
      It has nothing to do with redoing venv: some package installs were just taking multiple minutes. I cancelled one at 4 minutes before switching to uv and having it finish in a few seconds
      - guappa 2y ago
        If only linux distributions had existed for decades…
mcintyre1994 2y ago
That scripting trick is awesome! One of the really nice things about Elixir and its dependency manager is that you can just write Mix.install(…) in your script and it’ll fetch those dependencies for you, with the same caching you mentioned too. Does uv work with Jupyter notebooks too? When I used it a while ago dependencies were really annoying compared to Livebook with that Mix.install support.
- uasi 2y ago
  uv offers another useful feature for inline dependencies, which is the exclude-newer field[1]. It improves reproducibility by excluding packages released after a specified date during dependency resolution. I once investigated whether this feature could be integrated into Mix as well, but it wasn't possible since hex.pm doesn't provide release timestamps for packages. > Does uv work with Jupyter notebooks too? Yes![2] [1] https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility https://docs.astral.sh/uv/guides/scripts/#improving-reproduc... [2] https://docs.astral.sh/uv/guides/integration/jupyter/ https://docs.astral.sh/uv/guides/integration/jupyter/
y1zhou 2y ago
Adding dependencies to the script directly was a game-changer. I was able to write a script for a friend with no coding background at all and everything ran smoothly on his machine. No more rabbit holes of bundling Python packages and setting up environments!
fluidcruft 2y ago
I generally agree but one thing I find very frustrating (i.e. have not figured out yet) is how deal with extras well, particularly with pytorch. Some of my machines have GPU, some don't and things like "uv add" end up uninstalling everything and installing the opposite forcing a resync with the appropriate --extra tag. The examples in the docs do things like CPU on windows and GPU on Linux but all my boxes are linux. There has to be a way to tell it that "hey I want --extra GPU" always on this box. But I haven't figured it out yet.
- satvikpendem 2y ago
  This happened to me too, that is why I stopped using it for ML related projects and stuck to good old venv. For other Python projects I can see it being very useful however.
- 0xcoffee 2y ago
  Does this help? https://github.com/astral-sh/uv/pull/7851 https://github.com/astral-sh/uv/pull/7851
  - fluidcruft 2y ago
    I haven't tried it yet but that looks like exactly what I've been missing.
  - fluidcruft 2y ago
    Unfortunately it didn't seem to help https://news.ycombinator.com/threads?id=fluidcruft#43355636 https://news.ycombinator.com/threads?id=fluidcruft#43355636
- DrBenCarson 2y ago
  It sounds like you’re just looking for dependency groups? uv supports adding custom groups (and comes with syntactic sugar for a development group
  - fluidcruft 2y ago
actinium226 2y ago
The script thing is great. By the way those 'oddly formatted' comments at the top are not a uv thing, it's a new official Python metadata format, specifically designed to make it possible for 3rd party tools like uv to figure out and install relevant packages. And in case it wasn't clear to readers of your comment, uv run script.py creates an ephemeral venv and runs your script in that, so you don't pollute your system env or whatever env you happen to be in.
para_parolu 2y ago
As a person who don’t work often on python code but occasionally need to run server or tool I find UV blessing. Before that I would beg people to help me just not to figure out what combination of obscure python tools I need. Now doing “uv run server.py” usually works.
ibic 2y ago
I happened to use uv recently for a pet project, and I totally agree with you. It's really really good. I couldn't believe its dependency resolution and pulling can be so fast. Imho, it's the python package manager (I don't know the most suitable name to categorize it) done right, everything just works, the correct way.
crabbone 2y ago
> It solves & installs dependencies incredibly fast If you are lucky, and you don't have to build them, because the exceptionally gifted person who packaged them didn't know how to distribute them and the bright minds running PyPI.org allowed that garbage to be uploaded and made it so pip would install that garbage by default. > can replace pipx with "uv tool install," That's a stupid idea. Nobody needed pipx in the first place... The band-aid that was applied some years ago is now cast in stone... The whole idea of Python tools trying to replace virtual environment, but doing it slightly better is moronic. The virtual environments is the band-aid. It needs to go. The Python developers need to be pressured into removing this garbage, and instead working on having program manifests or something similar. Python has virtual environments due to incompetence of its authors and unwillingness to make things right, once that incompetence was discovered. ---- NB. As it stands today, if you want to make your project work well, you shouldn't use any tools that install packages by solving dependencies and downloading them from PyPI. It's not the function of the tool doing that, it's the bad design of the index. The reasonable thing to do is to install the packages (for applications) you need during development, figure out what you actually need, and then store the part you need for your package to work locally. Only repeat this process when you feel the need to upgrade. If you need packages for libraries, then you need a way to install various permutations within allowed versions: no tool for package installation today knows how to do it. So, you might as well not use any anyways. But, the ironic part is that nobody in Python community does it right. And that's why there are tons of incompatibilities, and the numbers increase dramatically when projects age even slightly.
- poulpy123 2y ago
  [flagged]
- quickslowdown 2y ago
  Uv addresses all of your complaints in an elegant way. It's ok if you don't understand its purpose, this list is confusing to me, it's incredibly specific and barely related to uv.
insane_dreamer 2y ago
uv is great and we’re switching over from conda for some projects. The resolver is lightning fast and the toml support is good. Having said that, there are 2 areas where we still need conda: - uv doesn’t handle non-python wheels, so if you need to use something like mkl, no luck - uv assumes that you want to use one env per project. However with complex projects you may need to use a different env with different branches of your code base. Conda makes this easy - just activate the conda env you want — all of your envs can be stored in some central location outside your projects — and run your code. Uv wants to use the project toml file and stores the packages in .venv by default (which you don’t want to commit but then need different versions of). Yes you can store your project venv elsewhere with an env var but that’s not a practical solution. There needs to be support for multiple .toml files where the location of the env can be specified inside the toml file (not in an env var).
- serjester 2y ago
  You may want to checkout uv’s workspaces - they’re very handy for large mono repos.
  - insane_dreamer 2y ago
    Thanks. I looked at that but I believe it solves a different problem.
- bogdart 2y ago
  You can create another venv in the same folder with different name. ‘uv venv my-name’ does the thing.
samuell 2y ago
Did you try pixi [1] too? [1] https://pixi.sh/latest/ https://pixi.sh/latest/
- quickslowdown 2y ago
  I have tried Pixi, I was a big fan, but at the time it involved a LOT of manually editing text files & I didn't want to deal with that. And now I have a hard time imagining installing from Conda could possibly be faster than the sheer speed of uv

midhun1234 2y ago

Can confirm this is all true. I used to be the "why should I switch" guy. The productivity improvement from not context switching while pip installs a requirements file is completely worth it.

baby_souffle 2y ago

I didn't know that UV would now edit the script for you. That is just icing on the cake! For the curious, the format is codified here: https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/

scribu 2y ago

The install speed alone makes it worthwhile for me. It went from minutes to seconds.

BoorishBears 2y ago
I was working on a Raspberry Pi at a hackathon, and pip install was eating several minutes at a time. Tried uv for the first time and it was down to seconds.
- guappa 2y ago
  Why would you be redoing your venv more than once?
  - dagw 2y ago
    Once rebuilding your venv takes negligible time, it opens up for all kinds of new ways to develop. For example I now always run my tests in a clean environment, just to make sure I haven't added anything that only happens to work in my dev venv.
    - kstrauser 2y ago
      That's smart. Oh, you used `pip install` to fix a missing import, but forgot to add it to pyproject.toml? You'll find out quickly.
    - guappa 2y ago
      I thought you wanted to test your program, but seems you want to make sure that your unzip library keeps working :D
  - BoorishBears 2y ago
    It has nothing to do with redoing venv: some package installs were just taking multiple minutes. I cancelled one at 4 minutes before switching to uv and having it finish in a few seconds
    - guappa 2y ago
      If only linux distributions had existed for decades…

mcintyre1994 2y ago

That scripting trick is awesome! One of the really nice things about Elixir and its dependency manager is that you can just write Mix.install(…) in your script and it’ll fetch those dependencies for you, with the same caching you mentioned too. Does uv work with Jupyter notebooks too? When I used it a while ago dependencies were really annoying compared to Livebook with that Mix.install support.

uasi 2y ago
uv offers another useful feature for inline dependencies, which is the exclude-newer field[1]. It improves reproducibility by excluding packages released after a specified date during dependency resolution. I once investigated whether this feature could be integrated into Mix as well, but it wasn't possible since hex.pm doesn't provide release timestamps for packages. > Does uv work with Jupyter notebooks too? Yes![2] [1] https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility https://docs.astral.sh/uv/guides/scripts/#improving-reproduc... [2] https://docs.astral.sh/uv/guides/integration/jupyter/ https://docs.astral.sh/uv/guides/integration/jupyter/

y1zhou 2y ago

Adding dependencies to the script directly was a game-changer. I was able to write a script for a friend with no coding background at all and everything ran smoothly on his machine. No more rabbit holes of bundling Python packages and setting up environments!

fluidcruft 2y ago

I generally agree but one thing I find very frustrating (i.e. have not figured out yet) is how deal with extras well, particularly with pytorch. Some of my machines have GPU, some don't and things like "uv add" end up uninstalling everything and installing the opposite forcing a resync with the appropriate --extra tag. The examples in the docs do things like CPU on windows and GPU on Linux but all my boxes are linux. There has to be a way to tell it that "hey I want --extra GPU" always on this box. But I haven't figured it out yet.

satvikpendem 2y ago
This happened to me too, that is why I stopped using it for ML related projects and stuck to good old venv. For other Python projects I can see it being very useful however.
0xcoffee 2y ago
Does this help? https://github.com/astral-sh/uv/pull/7851 https://github.com/astral-sh/uv/pull/7851
- fluidcruft 2y ago
  I haven't tried it yet but that looks like exactly what I've been missing.
- fluidcruft 2y ago
  Unfortunately it didn't seem to help https://news.ycombinator.com/threads?id=fluidcruft#43355636 https://news.ycombinator.com/threads?id=fluidcruft#43355636
DrBenCarson 2y ago
It sounds like you’re just looking for dependency groups? uv supports adding custom groups (and comes with syntactic sugar for a development group
- fluidcruft 2y ago

actinium226 2y ago

The script thing is great. By the way those 'oddly formatted' comments at the top are not a uv thing, it's a new official Python metadata format, specifically designed to make it possible for 3rd party tools like uv to figure out and install relevant packages. And in case it wasn't clear to readers of your comment, uv run script.py creates an ephemeral venv and runs your script in that, so you don't pollute your system env or whatever env you happen to be in.

para_parolu 2y ago

As a person who don’t work often on python code but occasionally need to run server or tool I find UV blessing. Before that I would beg people to help me just not to figure out what combination of obscure python tools I need. Now doing “uv run server.py” usually works.

ibic 2y ago

I happened to use uv recently for a pet project, and I totally agree with you. It's really really good. I couldn't believe its dependency resolution and pulling can be so fast. Imho, it's the python package manager (I don't know the most suitable name to categorize it) done right, everything just works, the correct way.

crabbone 2y ago

> It solves & installs dependencies incredibly fast If you are lucky, and you don't have to build them, because the exceptionally gifted person who packaged them didn't know how to distribute them and the bright minds running PyPI.org allowed that garbage to be uploaded and made it so pip would install that garbage by default. > can replace pipx with "uv tool install," That's a stupid idea. Nobody needed pipx in the first place... The band-aid that was applied some years ago is now cast in stone... The whole idea of Python tools trying to replace virtual environment, but doing it slightly better is moronic. The virtual environments is the band-aid. It needs to go. The Python developers need to be pressured into removing this garbage, and instead working on having program manifests or something similar. Python has virtual environments due to incompetence of its authors and unwillingness to make things right, once that incompetence was discovered. ---- NB. As it stands today, if you want to make your project work well, you shouldn't use any tools that install packages by solving dependencies and downloading them from PyPI. It's not the function of the tool doing that, it's the bad design of the index. The reasonable thing to do is to install the packages (for applications) you need during development, figure out what you actually need, and then store the part you need for your package to work locally. Only repeat this process when you feel the need to upgrade. If you need packages for libraries, then you need a way to install various permutations within allowed versions: no tool for package installation today knows how to do it. So, you might as well not use any anyways. But, the ironic part is that nobody in Python community does it right. And that's why there are tons of incompatibilities, and the numbers increase dramatically when projects age even slightly.

poulpy123 2y ago
[flagged]
quickslowdown 2y ago
Uv addresses all of your complaints in an elegant way. It's ok if you don't understand its purpose, this list is confusing to me, it's incredibly specific and barely related to uv.

insane_dreamer 2y ago

uv is great and we’re switching over from conda for some projects. The resolver is lightning fast and the toml support is good. Having said that, there are 2 areas where we still need conda: - uv doesn’t handle non-python wheels, so if you need to use something like mkl, no luck - uv assumes that you want to use one env per project. However with complex projects you may need to use a different env with different branches of your code base. Conda makes this easy - just activate the conda env you want — all of your envs can be stored in some central location outside your projects — and run your code. Uv wants to use the project toml file and stores the packages in .venv by default (which you don’t want to commit but then need different versions of). Yes you can store your project venv elsewhere with an env var but that’s not a practical solution. There needs to be support for multiple .toml files where the location of the env can be specified inside the toml file (not in an env var).

serjester 2y ago
You may want to checkout uv’s workspaces - they’re very handy for large mono repos.
- insane_dreamer 2y ago
  Thanks. I looked at that but I believe it solves a different problem.
bogdart 2y ago
You can create another venv in the same folder with different name. ‘uv venv my-name’ does the thing.

samuell 2y ago

Did you try pixi [1] too? [1] https://pixi.sh/latest/ https://pixi.sh/latest/

quickslowdown 2y ago
I have tried Pixi, I was a big fan, but at the time it involved a LOT of manually editing text files & I didn't want to deal with that. And now I have a hard time imagining installing from Conda could possibly be faster than the sheer speed of uv