TL;DR: uv is an extremely fast Python package manager, written in Rust.
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.
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 pip with pip are documented here: https://docs.astral.sh/uv/pip/compatibility/
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.
It’s written in Rust.
All jokes about the Rust Evangelism Strike Force aside, various parts of the industry are finally starting to think that “If it’s written in Rust, we have less to worry about with respect to that thing, so we won’t torture the devs and force them to sneak it in the side door anyway.”
It’s a thing that I’ve been seeing at work for the last few years.
Looks nice. The edge cases will be what determines if it gains adoption
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 different condas there’s a ton of fragmentation, and none of them do everything you’d want in an ideal way. above and beyond speed, i think uv is another attempt at it. but it could just be another classic xkcd moment where now there’s just another standard to deal with
uv is a drop-in replacement for pip. There’s no extra standard. It’s pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is…
as you might have guessed i haven’t really tried it, but i have been reading about it. that said i have used “drop in replacement” tools like this (we use pnpm at work), and a drop in replacement is not without quirks. they wouldn’t have made a different tool altogether if it was really a 1:1 replacement. just because the commands are the same doesn’t mean it behaves the same. i.e. i doubt one person on the team could be using uv while everyone else sticks to pip
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.
Yes. For the project I work on pip install takes about 60 seconds and replacing it with uv reduces 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.
I dunno maybe once a week or so? We don’t actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.
And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.
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.
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.
