Astral’s uv has taken the Python world by storm, and for good reason. It is blisteringly fast, handles Python versions with ease, and replaces a half-dozen tools with a single binary. I’ve written multiple articles about it before.
Getting started with a new Python project using uv and adding your first dependencies is very easy. But once you move past the initial setup and into the maintenance phase of a project, i.e. checking for outdated packages and performing routine upgrades, the CLI starts to feel surprisingly clunky compared to its peers like pnpm or Poetry.
Finding outdated packages
In my JavaScript projects, if I want to see what needs an update, I run:
$ pnpm outdated
This gives a clean, concise list of outdated packages, their current version, the latest version, and the version allowed by your constraints.
In uv, there is no uv outdated. Instead, you have to memorize the following mouthful:
$ uv tree --outdated --depth 1
The output is also a problem. It doesn’t just show you what is outdated; it shows you your entire top-level dependency tree, with a small annotation next to the ones that have updates available. If you have 50 dependencies and only two are outdated, you still have to scan a 50-line list.
Poetry isn’t much better with its command poetry show --outdated, but at least it only shows actual outdated packages.
Unsafe version constraints by default
This is the most significant philosophical departure uv takes from pnpm and Poetry, and it’s a dangerous one for production stability.
How pnpm/Poetry handle it
When you add a package using pnpm add, it writes it to package.json using the caret requirement (^1.23.4). The caret at the beginning means that any 1.x.x version is allowed, but it will not update to 2.0.0.
Poetry does the same by default, using a format like >=1.23.4,<2.0.0. I find this less readable than ^1.23.4, but the effect is the same.
In both cases, updates are safe by default. You can run pnpm update or poetry update every morning and have high confidence that your build won’t break due to a major API change (assuming the packages you depend on respect SemVer).
How uv handles it
When you run uv add pydantic, it inserts this into your pyproject.toml:
dependencies = [
"pydantic>=2.13.4",
]
Note the lack of an upper bound. In the eyes of uv, pydantic version 2, 3, and 100 are all perfectly acceptable.
This means uv updates are unsafe by default. If you run a bulk update, you aren’t just getting bug fixes; you are opting into every breaking change published by every maintainer in your dependency graph.
The bad UX of the upgrade command
The commands to actually perform an update in uv feel like they were designed for machines rather than humans.
If you want to update everything in pnpm or Poetry, it’s a simple pnpm update or poetry update command. In uv, you use:
$ uv lock --upgrade
Because of the “no upper bounds” issue mentioned above, uv lock --upgrade is a nuclear option. It will upgrade every single package in your lockfile to their absolute latest versions, ignoring SemVer safety. And this includes deep, nested dependencies you’ve never heard of! Good luck, better hope there are no breaking changes anywhere.
Once you realize this is too risky, you’ll want to upgrade only specific packages. After scouring the subpar output of uv tree --outdated --depth 1 to find them, the syntax becomes a repetitive chore.
How pnpm does it:
$ pnpm update pydantic httpx uvicorn
How uv does it:
$ uv lock --upgrade-package pydantic --upgrade-package httpx --upgrade-package uvicorn
Having to repeat the --upgrade-package flag for every single item is a huge hassle when you want to update a bunch of packages. I don’t understand why the UX of uv’s commands is so poor.
There is hope: the bounds flag
Luckily uv has recently introduced a --bounds option for uv add:
$ uv add pydantic --bounds major
This produces the safer pydantic>=2.13.4,<3.0.0 constraint we’ve come to expect. However, this is currently an opt-in feature. You have to remember to type it every time, and as of now, it is considered a preview feature.
Until --bounds major (or a similar configuration) becomes the default behavior, uv users are essentially forced to choose between two bad options:
- Manually edit
pyproject.tomlto add upper bounds for every single dependency. - Live in fear that
uv lock --upgradewill accidentally pull in a breaking major version change.
What I’d like to see
I love uv. Its speed is transformative, and the way it manages Python toolchains is second to none. But as a package manager, the developer experience for maintaining a project is currently a step backward from the tools that came before it.
We need a dedicated uv outdated command that filters noise, a more ergonomic update command that doesn’t require repeating flags, and default version constraints that respect the sanity of Semantic Versioning.
Until then, I’ll be double-checking every single line of my lockfile changes with a healthy dose of suspicion.
