Hacker News Reader

Comment by adhamsalama | Hacker News Reader

What benefits does uv have over poetry?

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.

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

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.

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.

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

Speed, compatibility, ergonomics, standards compliance.

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

Works with pytorch.

Reply on news.ycombinator.com