It's probably worth mentioning that Astral (The team behind uv/etc) has a team filled with people with a history of making very good CLI tooling. They probably have a very good sense for what matters in this stuff, and are thus avoiding a lot of pain.
Motivation is not enough, there's also a skill factor. And being multiple people working on it "full time"-ish means you can get so much done, especially before the backwards compat issues really start falling into place
It sounds like uv is a drop-in replacement for pip, pipx, and poetry with all of their benefits and none of the downsides, so I don't see why I wouldn't migrate to it overnight.
Then I gave it a try and it just worked! It’s so much better that I immediately moved all my Python projects to it.
Pip, venv and virtualenvwrapper (people still use this?) are not meaningfully "dependency managers". A venv is just a place to put things, and pip does only basic tracking and tries to maintain a consistent environment. It isn't trying to help you figure out what dependencies you need, create new environments from scratch, update pyproject.toml....
Pip's core capability is the actual installation of packages, and uv does a far better job of that part, using smarter caching, hard links to share files, parallelized pre-compilation of .pyc files, etc. Basically it's designed from the ground up with the intention to make lots of environments and expect starting a new one to be cheap. Poetry, as far as I was able to determine, does it basically the same way as pip.
Poetry which I think is the closest analogue, still requires a [tool.poetry.depenencies] section afaik.
uv init
uv add package
uv run program.py
That's it.If you inherit a codebase made this way from someone else, merely running uv run program.py will automatically create, launch the venv, configure packages, run your script, seamlessly on first launch.
Uv lets you almost forget virtual environments exist. Almost.
For everyone else, just try uv and don’t look back.