[jasongill]

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]

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]

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]

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.