uv: Unified Python packaging
uv: Unified Python packaging
Manage entire Python projects and even Python itself with a single unified tool.
TL;DR: uv is an extremely fast Python package manager, written in Rust.
Obligatory “there are now 15 competing standards”
For real though, this looks interesting. I am a long time poetry user, I’ve been mostly happy with it but I do think it could stand to be a little faster. I’ll have to try this out sometime.
uvis fantastic. I would highly recommend it. I've used it in a quite complex environment, with no issues (quite an achievement!) and it's about 10x faster than pip.I mean... I guess it's not surprising given
uvis written in Rust and pip is written in Python, but even so given pip is surely IO bound I was expecting something like 4x improvement. 10x is impressive.The actual dependency resolution part, so where you figure out which versions of the dependencies can be used together, is actually notoriously CPU-bound.
At least as far as I'm aware, you generally use a SAT solver for dependency resolution (unless you don't care for correctness), and as Wikipedia puts it:
Boolean satisfiability is an NP-complete problem in general. As a result, only algorithms with exponential worst-case complexity are known.
There are quite sophisticated algorithms at this point, making use of heuristics and whatnot, but they're still just backtracking algorithms at their core. And as Wikipedia puts it so fittingly again:
backtracking is often much faster than brute-force enumeration
You know shit's inefficient, when the best thing to compare it to, is just randomly trying solutions.
Interestingly, dependency resolution is not the only NP hard problem uv tries to solve. During development, it also became clear that we needed some way to simplify PEP 508 marker expressions and ask questions like, "are these marker expressions disjoint?"
you generally use a SAT solver for dependency resolution (unless you don’t care for correctness)
Actually Go's dependency system is specifically designed to avoid the need for global constraint solvers. Go has the most modern and elegant dependency versioning system that I'm aware of. Python was designed before people realised that it's dependency style was a mistake.
uv is now capable of installing and managing Python itself, making it entirely self-bootstrapping:
Looking forward to this. One of the blind spots of poetry was to ignore the issue of managing python versions themselves. I'm happy to see they're covering so many aspects of dependency management and replicability.
This is incredible. Truly hats off to the folks at Astral. Can't wait to try all this out and replace all our old bespoke tooling.
Having used it for work, I really don't understand the appeal, especially when compared to tools like Poetry. Uv persists in the dependency on requirements.txt, doesn't streamline the publishing process, and contrary to the claims, it's not a drop-in replacement for pip, as the command line API is different.
It's really fast, which is nice if you're working on a nightmare codebase with 3000 dependencies, but most of us aren't, and Poetry is pretty damned fast.
If uv offered some of what Poetry does for me, if at the very least we could finally do away with requirements.txt and adopt something more useable -- baked into pyproject.toml of course -- then I'd be sold. But this is just faster pip.
Early on uv was only trying to replace pip. This latest update is a big step towards becoming a poetry (and pyenv/pipx) replacement too.
uv 0.3 introduces a cross platform lock file: https://docs.astral.sh/uv/concepts/projects/#lockfile
More precise details on the compatibility of
uv pipwithpipare documented here: https://docs.astral.sh/uv/pip/compatibility/Uv is currently only a pip replacement as a dependency resolver (and downloader), it was actually adopted by astral from a different dev afaik
Their vision is to evolve it into a "Cargo for Python", so it's coming.
Is that a real problem? I've never considered that a python package manager should be or could be faster.
To be fair, I don't use python professionally.
definitely not the real reason for a project like this to exist. Python package management can be nightmarish at times depending on what you’re doing. between barebones
requirements.txt, Poetry, and the differentcondas there’s a ton of fragmentation, and none of them do everything you’d want in an ideal way. above and beyond speed, i thinkuvis another attempt at it. but it could just be another classic xkcd moment where now there’s just another standard to deal withYes. For the project I work on
pip installtakes about 60 seconds and replacing it withuvreduces that to about 7 seconds. That's a very significant improvement. Much less annoying interactively and in CI we do this multiple times so it saves a significant chunk of time.The performance is just a "nice to have".
Python package management, especially at scale is infuriating. At work we use python microservices in docker containers and it infuriates me trying to update the one our team is responsible for.
I always like to rant that python 3rd party package management tools are a mistake. We should've gone for an "as simple as possible" setup instead of all this.
So I'm sceptical of UV on principle since it's yet another 3rd party package manager but if it can do all of this and not be a nightmare I'll be ok with it.
Very impressive results. I think I’ll give the tool a try next time we’re working on a small project. I’m dissatisfied with the existing packaging solutions.
Isn't
uvbeing used as a package manager/resolver inrye? I'm usingryefor my new projects and it's nice becauseruffandpytestare being unified in it too.Yeah it is, eventually they want UV to have feature parity with rye and rye will basically just be a pointer to UV
Rye's developer on their plans for Rye in the context of uv's latest release:
This is great!
@[email protected], do you know is Astral is working with prefix.dev and their Pixi project? They seem to now have overlapping concerns.
I don't think they have anything to do with each other, it looks like prefix.dev uses conda packages.
Conda is their primary focus, but they support well more than conda packages.
Looks nice. The edge cases will be what determines if it gains adoption