uv: An extremely fast Python package and project manager, written in Rust

Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought.

I now use uv for everything Python. The reason for the switch was a shared server where I did not have root and there were all sorts of broken packages/drivers and I needed pytorch. Nothing was working and pip was taking ages. Each user had 10GB of storage allocated and pip's cache was taking up a ton of space & not letting me change the location properly. Switched to uv and everything just worked

If you're still holding out, really just spend 5 minutes trying it out, you won't regret it.

> Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought

Really? :)

requirements.txt is just hell and torture. If you've ever used modern project/dependency management tools like uv, Poetry, PDM, you'll never go back to pip+requirements.txt. It's crazy and a mess.

uv is super fast and a great tool, but still has roughnesses and bugs.

Pip-tools+requirements.txt helped me survive the past few years. I also never thought I needed uv, but after all the talk about it I gave it a spin and never want back. It’s just so blazing fast en convenient.

pip also works with pyproject.toml. Sticking with requirements.txt is a self-imposed constraint.

I wonder how it compares with something more green generalist like "mise", to which I migrated after using "ASDF" for some time.

I use both! uv installed globally with mise, and uv tools can then be managed via “miss use -g pipx:foo”.

> Each user had 10GB of storage allocated and pip's cache was taking up a ton of space & not letting me change the location properly. Switched to uv and everything just worked

Is it better about storage use? (And if so, how? Is it just good at sharing what can be shared?)

uv hardlinks identical packages, so adding virtual envs takes up very little space.

Unless you cross mount points, which uv will helpfully warn about.

For me, the big key was: uv is so much easier to explain and especially use - especially for people who sometimes script something in python and don't do this daily.

pip + config file + venv requires you to remember ~2 steps to get the right venv - create one and install stuff into it, and for each test run, script execution and such, you need to remember a weird shebang-format, or to activate the venv. And the error messages don't help. I don't think they could help, as this setup is not standardized or blessed. You just have to beat a connection of "Import Errors" to venvs into your brain.

It's workable, but teaching this to people unfamiliar with it has reminded me how.. squirrely the whole tooling can be, for a better word.

Now, team members need to remember "uv run", "uv add" and "uv sync". It makes the whole thing so much easier and less intimidating to them.

We use uv to compile requirements.txt from pyproject.toml to get the locked versions.

    # Makefile
    compile-deps:
     uv pip compile pyproject.toml -o requirements.txt
    
    compile-deps-dev:
     uv pip compile --extra=dev pyproject.toml -o requirements.dev.txt

I remember using pip and venv back in like 2009. Last time I checked, maybe 5 or 10 years ago, the recommendation of the community was generally to just use Docker instead of all these tools. Did that not catch on?

I came here to comment that I don’t see any reason to bother - that’s for the comment, I will try it now!

There is a global cache for all installed packages in the user home cache dir.

The advice seems to change every year. For a while it was venv, then pipenv, poetry, docker, and now uv. Maybe the ecosystem will settle on that but who knows.

The absolute killer feature for me of uv is that it's still compatible with all of my old venv-based workflows. Just run `uv venv`.

In those situations, have you had a any luck using UV_LINK_MODE=symlink? I eventually had to resort to `copy` mode because it seemed the folder names (hashes) uv created in the package cache were not fully deterministic. So sometimes my cache volume would change and my Docker build would break. :\

Similarly to the sibling I also use both. I let mise manage my uv version (and other tools) and let uv handle Python + PyPI Packages for me. Works great!

There's also some additional integration which I haven't tried yet: https://mise.jdx.dev/mise-cookbook/python.html#mise-uv

I love uv. The one gotcha I'll warn people about is: don't touch uvx. I've lost an embarrassing number of hours or days trying to figure out why nothing works properly or makes sense when I tried to run things with uvx. I guess I understand why it's there, but I think it's a built-in foot-gun and not well documented. But if you stay away from it, things work great.

Both pip and uv cache packages to ~/.cache. Uv lets you change it to /tmp and symlink instead of copying

similar story recently with an experimental repo that starts with "its so easy, just $uv a b c" .. under the hood it implies a lot of redundancies? but true enough it worked fine and trouble-free too, on a standard GNU-Debian-Ubuntu host

What for? Support legacy CI/CD pipelines or something like that? uv.lock already contains locked versions of all dependencies plus a lot of other needed metadata.

uvx is fine. I use it to run executable packages all the time. What is your problem with it?

Same! I recently set up some dev environments with mise. My old ones are still using poetry, the new ones have uv. uv is incredibly snappy. It's like night and day!

What has been holding me back on uv is my experience with Ruff. Ruff claims "Drop-in parity with Flake8, isort, and Black", but that is simply not true. At least for isort, Ruff only re-implemented what they wanted and then ask you to use Ruff to call out to the old isort tool if there's a feature or setting that's missing in the Ruff re-implementation. So what's the point? Ruff just partially re-implemented many existing different tools and added some new ones. So using Ruff actually increases the amount of tools, yet again, you're having to use because of this and it also not doing everything that Pylint does.

For moving to uv, I haven't heard a good story for what uv provides over Poetry rather than "is fast". The only unique thing that I am currently aware of is that uv can install Python itself, which gets rid of tools like Pyenv. I'm interested because of that, but "is fast" isn't enough of a reason.

What issues are you having with uvx? It replaces tools like pipx that set up implicit venvs to run specific tools. Works great for me.

I suppose you didn't accompany the command `uvx` with the necessary `--with=` arguments[1] for each dependency.

[1] https://docs.astral.sh/uv/guides/tools/#commands-with-plugin...

> What for? Support legacy CI/CD pipelines

Yes. Azure, for instance, looks for requirements.txt if you deploy a web app to Azure App Service.

If you’re doing a code-based deployment, it works really well. Push to GitHub, it deploys.

You can of course do a container-based deployment to Azure App Service and I’d assume that will work with uv.

My experience is that ruff reimplemented 99% of the most popular features of black, isort, flake8, pylint, etc. and then added 10000% more features on top, that feels like a fair tradeoff to me.

I've converted multiple large Python codebases to ruff, and each time I just configure ruff as close to the previous tools as possible, then reformat the entire codebase with ruff and remove all the previous tools. The speed increase when linting alone is worth the minor formatting changes to me.

If you really insist on keeping isort's sorting then you could at least replace black and pylint, which would reduce the total number of tools by one.

I mean docker is orthogonal to package manager. It makes it easier to deploy but none of the other thing also have managers do are relevant.

Docker was always a workaround to Python not having a non-awful dependency manager. uv is that non-awful dependency manager, and I expect in the long term it will reduce the use of Docker.

Think of uv more as like npm or other thing like that. The new Python pyproject.toml is similar package.json. It defines the project description, list of dependencies, and other hooks. Uv is a package/project tool using pyproject.toml. It is easy to manage dependencies, build and publish to PyPi, add hooks to run tests, linters, or whatever, again much like package.json. It also manages the virtualenv automatically, though you can manage it yourself.

Thanks for mentioning mise. I'm more interested in it for the task running feature. I couldn't figure out how to have shell scripts in Justfile, so I gave up on it.

Note: /tmp will take awhile to get rid of, but it's definitely on the chopping block.

I'd avoid workflows that lean on it, if anything else for security's sake.

"legacy CI/CD pipelines"

Damn I'm getting old

Just made the switch myself. Was far easier and smoother than I expected.

Docker solves a different problem. Docker is a way to basically ship your whole OS off to another machine. You still have to have a way to install the right version of python and all the python libraries you need inside the Docker container, and uv is great for this.

Secondly Docker only solves a subset of problems. It's fine if you're developing a server that you will be deploying somewhere. It's inconvenient if you're developing an end user application, and it's completely useless if you're developing a library you want people to be able to install.

Unfortunately uWSGI (one of the most important libraries) is fundamentally incompatible with uv. had to roll back all my apps that use custom uWSGI for that reason.

This is similar to things like poetry (poetry run ..., poetry add, poetry install), but yeah. Does look nice.

Could you explain how? Does it do something funky in the venv that uwsgi doesn't understand?

Out of interest - What wasn't working for you?

I use Just inside (and outside) mise, almost exclusively with embedded shell/python scripts. Have used mise tasks a little, but didn't meaningfully add enough for me

Or do you mean justfiles with shebangs?

Either way, curious what problem you hit (and may be able to unblock ya)

I think you're underestimating how "fast" uv really is. It's night and day different. The sentence that got me to switch and I echo still was: "uv is so fast, I sometimes don't even think it's actually doing anything". The first time I used it, I had to actually double check if uv actually was working and installing the packages that it was saying it was. There's a lot of reasons I've heard not to use it that kind of (not really) make sense (you don't want another package manager, you're happy with just base pip, etc). But if you're already using poetry, you really should just switch. uv is just poetry but without any waiting.

Even your most complicated projects should be able to switch within a day. The only reason I took any time was having to restructure my docker containers to work with uv instead of poetry. And that's mostly with my inexperience with docker, not because uv is complicated.

From what I remember, the task consisted of several lines of shell and just would just choke at some point. I think it was because I used a new line to visually separate code. I'm not sure, I don't remember exactly as it was some time ago and I just gave up.

Ah fair enough, thanks!

possibly patched now but definitely going to try breaking it now before moving any more stuff into it

I am using uwsgi with uv. This is not to say the problems you are facing are not real, but it cannot be a 'fundamental incompatibility' if it is working in my case. Here is an example of a CLI invocation I am using for quick testing:

-- uv run uwsgi --socket 0.0.0.0:8080 --protocol=http -w foo.app:server --processes 2 --threads 2 --stats 0.0.0.0:9191 --