Yeah, switched to writing python professionally ~4 years ago, and been low key hating the ecosystem. From a java and javascript background, it's mostly been npm/mvn install and it "just works". With python, there's always someone being onboarded that can't get it to work. So many small issues. Have to have the correct version per project, then have to get the venv running. And then installing it needs to build stuff because there's no wheel, so need to set up a complete c++ and rust toolchain etc., just to pull a small project and run it.

uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.

Ok, you convinced me to give it a try. Tbh, I am a casual user of python and I don't want to touch it unless I have a damn good reason to use it.

Now, if I hadn't read literally the same message for Pipenv/Pipfile and poetry before, too...

Python is going through package managers like JS goes through trends like classes-everywhere, hooks, signals etc

But how does it work with components that require libraries written in C?

And what if there are no binaries yet for my architecture, will it compile them, including all the dependencies written in C?

What about using https://github.com/RustPython/RustPython also?

That's rough for all the creators of poetry, pdm, pipenv, etc. to hear. They put in a ton of great work over the last decade, but I fear you may be right.

I’m a bit confused why uv is not an option for you. You don’t need to compile Python, it manages virtualenvs for you, you can use them with Jupyter and vscode. What are you missing?

Have you checked out https://github.com/prefix-dev/pixi? It's built by the folks who developed Mamba (a faster Conda implementation). It supports PyPI dependencies using UV, offers first-class support for multi-envs and lockfiles, and can be used to manage other system dependencies like CUDA. Their CLI also embraces much of the UX of UV and other modern dependency management tools in general.

I have moved to uv few months back and never looked back. I use it with venv and it works very well. There is a new environment handling way with uv:

- uv init new-py-env

- cd new-py-env

- uv add jupyter

- uv build

These are executed super fast. Not sure if this could help your situation but it is worth to be aware of these.

The python ecosystem has become a disaster. Even reading your post gave me a headache.

The benefit that uv adds is it's a one-stop-shop that's also wicked fast.

If you use venv then you have extra steps because you have to explicitly create the venv, then explicitly install the deps there with pip. If your project is designed for a specific python version then developers have to manage that separately (usually pyenv these days).

For people building apps uv replaces venv, pip and pyenv, while being way faster at doing all three of those (you can completely rebuild the virtualenv and install the dependencies from scratch in under a second usually because uv is faster at creating a virtualenv than venv and is very quick at relinking the dependencies from a package cache).

What makes it so great for me is the effortlessness.

I often use Python for quick one off scripts. With UV I can just do `uv init`, `uv add` to add dependencies, and `uv run` whatever script I am working on. I am up and running in under a minute. I also feel confident that the setup isn't going to randomly break in a few weeks.

With most other solutions I have tried in the Python ecosystem, it always seemed significantly more brittle. It felt more like a collection of hacks than anything else.

I'm in the same boat. Sure it's nice and better, but I haven't felt so much annoyance with the python ecosystem that I desperately need something better. I use VS Code and it takes care of venv automatically, so I am biased by that.

ty! We have no plans to rewrite Wagtail in Rust but I hope there’s ways in which we can make the developer experience better, particularly around dependencies management

With the caveat I only have the package installers usage data for Wagtail downloads – pdm usage has fallen off a cliff, from 0.2% of downloads in January 2024, to 0.01% in January 2025. Roughly matches the uptake of uv.

Doesn’t make pdm bad in itself but that means there’ll be fewer pdm users around to report bugs, potentially fewer contributors to it too, fewer resources, etc.

Back when PDM was still pushing __pypackages__ for standardisation I think PDM made sense, but honestly I don't think it adds anything over uv and is just going to be slower for the most part.

pdm actually supports using uv as the resolver

https://pdm-project.org/en/latest/usage/uv/

- uv is aware of your dependencies, you can add/remove development dependencies, create group of development dependencies (test, lint, dev, etc) and add or remove those and only those at will. You can add dependencies and optional dependencies for a project as well, think my_app[cli,standard]. You don't need to have different requirements.txt for each case nor do you need to remove things by hand as you'd do in pip, since it doesn't remove deps when you remove a package for example. As a result, you can remove {conda,poetry,...} from your workflows.

- uv can install python and a virtualenv for you. Any command you run with `uv run` from the root of a repo will be aware of its environment, you don't even need to activate a virtualenv anymore. This replaces {pyenv, pyenv-virtualenv, virtualenvwrapper,...}.

- uv follows the PEPs for project config (dependencies, optional dependencies, tool configs) in the pyproject.toml so in case uv dies, it's possible to migrate away for the features are defined in the PEPs. Which is not the case for say, poetry.

- uv has a lock file and it's possible to make deps platform specific (Windows, Linux, MacOS, etc). This is in compliance with a PEP but not supported by all tools.

- uv supports custom indexes for packages so you can prefer a certain index, for example your company package index or pytorch's own index (for ML work).

- very fast, makes local dev very seamless and is really helpful in CI/CD where you might just setup and tear down python envs a lot.

Also, the team is responsive on Github so it's easy to get help.

Not only it's faster, it also provides a lock file, `uvx tool_name` just like `npx`, and a comprehensive set of tools to manage your Python version, your venv and your project.

You don't need `pyenv`, `poetry` and `pipx` anymore, `uv` does all of that for you.

> over pip

It's a much more complete tool than pip. If you've used poetry, or (in other languages) cargo, bundler, maven, then it's like that (and faster than poetry).

If you haven't, in addition to installing dependencies it will manage and lock their versions (no requirements.txt, and much more robust), look after the environment (no venv step), hold your hand creating projects, and probably other things.

Edit to add: the one thing it won't do is replace conda et al, nor is it intended to.

The problems start as soon as your scripts should run on more than your own computer.

If you pip install something, you install it on the system python (the python binary located at sys.executable). This can break systems if the wrong combination of dependencies comes together. This is why you should never install things via pip for other people, unless you asked them first.

Now how else would you install them? There is a thing called virtual environments, which basically allows you to install pip dependencies in such way, they are only there within the context of the virtual environment. This is what you should do when you distribute python programs.

Now the problem is how do you ensure that this install to the virtual environment uses specific versions? What happens when one library depends on package A with version 1.0 and another library depends on a package with version 2.0? Now what happens if you deploy that to an old debian with an older python version.. Before uv I had to spend literal days to resolve such conflicts.

uv solves most of these problems in one unified place, is extremely performant, just works and when it does not, it tells you precisely why.

The whole explaination is here: https://www.bitecode.dev/p/a-year-of-uv-pros-cons-and-should

The td;rd is that is has a lot less modes of failure.

It brings way more to the table than just being fast, like people are commenting. E.g. it manages Python for your projects, so if you say you want Python 3.12 in your project, and then you do 'uv run python my script.py', it will fetch and run the version of Python you specified, which pip can't do. It also creates lock files, so you know the exact set of Python package dependencies that worked, while you specify them more loosely. Plus a bunch of other stuff..

The only advantage over pip is it's faster. But the downside is it's not written in Python.

The real point of uv is to be more than pip, though. It can manage projects, so basically CLI commands to edit your `pyproject.toml`, update a lockfile, and your venv all in one go. Unlike earlier tools it implements a pretty natural workflow on top of existing standards where possible, but for some things there are no standards, the most obvious being lockfiles. Earlier tools used "requirements.txt" for this which was quite lacking. uv's lockfile is cross-platform, although, admittedly does produce noisier diffs than requirements.txt, which is a shame.

Faster.