4 ms·

What benefits does uv have over poetry?

by adhamsalama 2y ago

the_mitsuhiko 2y ago
Speed, compatibility, ergonomics, standards compliance.
- baggiponte 2y ago
  also a whole bunch of new features (--script mode), speed of development, a stacked team.
jasongill 2y ago
uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks
- zahlman 2y ago
  I really haven't been able to understand why "managing the Python version" is such a big value add for so many people. I just have each version built from source and make venvs from them as needed.
  - jasongill 2y ago
    Because most people don't build their toolchain from source anymore. When I am trying to help a junior programmer get up and going, it's a lot easier to say "OK, just do `brew install uv` then `uv sync` in the project folder and you are all set" than to try to walk them through building from source. Not to mention being able to have reproducible builds for deployments, CI/CD, etc. The fact that the Python version is picked up from the project's package configuration is nice because then you don't have to remember to update the source build to match when you update pyproject.toml for a new Python release.
    - zahlman 2y ago
      I happen to have built the interpreters (not an entire toolchain) from source. But I could equally well have obtained them from a PPA or whatever else. On Windows I could have used the official installers. The point is that once I have base environments, creating venvs is trivial. (And really, the experience of building Python from source on Mint was about as smooth as I could have ever hoped for.) >when you update pyproject.toml for a new Python release. ? I don't upper-cap the Python version (or anything else without a well-defined reason - https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ ) so I wouldn't be updating anyway. If I want to test under a new Python version then I need to write that out explicitly somewhere regardless; might as well do it on the command line.
throwaway314155 2y ago
Works with pytorch.
dagw 2y ago
In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.

What benefits does uv have over poetry?

the_mitsuhiko 2y ago

Speed, compatibility, ergonomics, standards compliance.

baggiponte 2y ago
also a whole bunch of new features (--script mode), speed of development, a stacked team.

jasongill 2y ago

uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks

zahlman 2y ago
I really haven't been able to understand why "managing the Python version" is such a big value add for so many people. I just have each version built from source and make venvs from them as needed.
- jasongill 2y ago
  Because most people don't build their toolchain from source anymore. When I am trying to help a junior programmer get up and going, it's a lot easier to say "OK, just do `brew install uv` then `uv sync` in the project folder and you are all set" than to try to walk them through building from source. Not to mention being able to have reproducible builds for deployments, CI/CD, etc. The fact that the Python version is picked up from the project's package configuration is nice because then you don't have to remember to update the source build to match when you update pyproject.toml for a new Python release.
  - zahlman 2y ago
    I happen to have built the interpreters (not an entire toolchain) from source. But I could equally well have obtained them from a PPA or whatever else. On Windows I could have used the official installers. The point is that once I have base environments, creating venvs is trivial. (And really, the experience of building Python from source on Mint was about as smooth as I could have ever hoped for.) >when you update pyproject.toml for a new Python release. ? I don't upper-cap the Python version (or anything else without a well-defined reason - https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ ) so I wouldn't be updating anyway. If I want to test under a new Python version then I need to write that out explicitly somewhere regardless; might as well do it on the command line.

throwaway314155 2y ago

Works with pytorch.

dagw 2y ago

In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.