For about a decade, the honest answer to “which Python package manager should I use” was a shrug followed by “pip and a requirements.txt, probably.” Then Poetry made lockfiles normal. Then PDM showed up with some genuinely good ideas. And then Astral’s uv arrived, written in Rust, and started eating everyone’s lunch.
If you’re picking a toolchain in 2026 — or thinking about migrating an existing one — the landscape finally looks different enough to be worth a real comparison. Not a feature-checklist dump, but an actual opinion about what to use and when. So here’s mine, with the benchmarks to back it up.
The state of Python packaging in 2026
The big story is that uv overtook Poetry. As of early-to-mid 2026, uv pulls roughly 75 million monthly downloads on PyPI against Poetry’s ~66 million. That’s a remarkable shift for a tool that didn’t exist before 2024. People don’t switch package managers for fun — it’s painful — so a swing that size tells you something real is happening.
What’s happening is mostly speed, and I’ll get to the numbers. But there’s also a consolidation angle. uv doesn’t just install packages. It manages virtual environments, installs Python interpreters (goodbye pyenv), runs scripts, and builds projects. It’s trying to be the one tool, the way Cargo is for Rust. Poetry and PDM are project managers too, but uv folded in the Python-version-management piece that used to need a separate tool entirely.
One thing to clear up, because the hype gets ahead of reality: uv is not at version 1.0. As of May 2026 it’s sitting around the 0.11.x line. The developers have been clear that the pre-1.0 number doesn’t mean “unstable toy” — plenty of companies run it in production CI — but it does mean the CLI and config can still shift between releases. Pin your uv version in CI and you’ll be fine. Just don’t believe anyone who tells you it shipped a 1.0.
Speed: this is where uv wins, and it’s not close
Let me put the numbers up front, because they’re the whole reason this conversation exists. These are for a fairly typical Django-plus-some-ML project with around 80 dependencies, cold cache:
| Tool | Cold install (~80 deps) |
|---|---|
| uv | ~8 seconds |
| PDM | ~38 seconds |
| Poetry | ~50 seconds |
| pip | ~90 seconds |
And for the operations you actually repeat all day:
- Cold install from a lockfile: uv ~3s vs Poetry ~11s
- Lockfile generation: uv ~8s vs Poetry ~22s
uv is generally cited as 10–100x faster than pip and roughly 10x faster than Poetry on the operations that matter — resolution, install, venv creation. The exact multiple depends on your dependency tree and how warm your cache is, but the direction never changes. uv is faster every single time.
Why does it matter beyond bragging rights? CI. If your pipeline runs on every push and every PR, shaving 40 seconds off the install step adds up fast across a team. I’ve watched a CI stage drop from “go get coffee” to “blink and you missed it” purely from swapping pip for uv, with zero other changes. That’s the kind of win that pays for the migration on its own.
The caveat: for a tiny project with five dependencies, none of this is noticeable. If your requirements.txt has six lines, pip installs in two seconds and uv installs in half a second, and you will not feel the difference. Speed is a fleet problem, not a hobby-script problem.
Feature-by-feature, where it actually differs
Speed isn’t the only axis, and if it were, this would be a one-line article. Here’s how the four stack up on the things teams actually argue about.
Lockfiles
Poetry, PDM, and uv all produce cross-platform lockfiles with hashes — the thing plain pip never gave you out of the box. pip can fake it with pip-tools (pip-compile), and a lot of shops still do exactly that and are perfectly happy. But it’s a bolt-on, not a built-in.
uv’s lockfile is fast to generate (those 8 seconds vs Poetry’s 22) and it’s universal — one lockfile resolves for all platforms rather than locking you to the machine that generated it. Poetry’s lockfile format has matured a lot and is rock-solid at this point; the difference now is resolution speed, not correctness.
Workspaces and monorepos
If you’ve got a monorepo with multiple Python packages, this is a real differentiator. uv has first-class workspace support — uv sync --all-packages to sync everything, uv run --package api ... to run a command inside one member. Poetry added better monorepo and workspace handling through 2026, closing what used to be a real gap. PDM has workspace support too. If monorepo ergonomics are your deciding factor, uv and current Poetry are both credible; older Poetry guides will steer you wrong here, so check the version.
Python version management
This is uv’s quiet superpower. uv python install 3.12 downloads and manages interpreters directly, which means you can drop pyenv from your setup entirely. Poetry and PDM expect you to bring your own Python. For a new machine or a fresh CI image, uv handling both the interpreter and the packages in one tool genuinely simplifies things.
PDM and the PEP 582 story
PDM’s original pitch was PEP 582 — installing packages into a project-local __pypackages__ directory so you don’t need a virtual environment at all. Neat idea. The problem: PEP 582 was rejected by the Python steering council, so it never became a standard, and the feature has been deprecated rather than blessed. PDM still works fine as a fast, standards-compliant manager with good lockfiles, but its headline differentiator turned into a dead end. That’s a big part of why PDM, despite being genuinely good, keeps getting squeezed — it doesn’t have a single thing uv doesn’t also do, faster.
The OpenAI question: does the acquisition change the risk calculus?
Here’s the part that made a lot of people nervous. On March 19, 2026, OpenAI announced it’s acquiring Astral — the company behind uv, the Ruff linter, and the ty type checker. The Astral team is joining OpenAI’s Codex group.
If you’re about to bet your team’s toolchain on uv, you should think about this rather than wave it away.
The reassurances are real. Charlie Marsh said open source is “at the heart” of what they do and that they’ll “keep building in the open.” OpenAI’s statement leaned on a “developer-first philosophy” and committed to supporting Astral’s open source products. And critically, uv and Ruff are permissively licensed — both Armin Ronacher and Douglas Creager pointed out that this makes them trivially forkable. Worst case, the community keeps the projects alive independently. That’s a meaningful safety net that, say, a proprietary tool would never give you.
The concerns are also real, and I don’t think they’re paranoid. Simon Willison raised the obvious one: a piece of critical Python infrastructure is now owned by a company with direct competitors in the AI space, and there’s at least a theoretical worry about OpenAI using ownership of uv as leverage. The fate of pyx, Astral’s commercial registry product, went conspicuously unmentioned in both announcements, which is the kind of silence that makes you wonder. And “we’ll explore deeper Codex integrations over time” is the sort of sentence that can mean anything.
My read: for the open source tool you run in CI, the acquisition barely moves the needle. The license makes it forkable, the userbase is enormous, and abandoning a tool with 75 million monthly downloads would be a self-inflicted wound nobody at OpenAI wants. I’d adopt uv today without losing sleep. What I’d watch is the commercial side — if you were evaluating pyx or any paid Astral product, that’s where the uncertainty actually lives, and I’d hold off until the post-acquisition roadmap is clearer.
So which one should you actually use?
Here’s where I stop hedging.
New project in 2026? Use uv. It’s the fastest, it handles Python versions and venvs for you, the workspace support is solid, and the ecosystem momentum means tutorials and Stack Overflow answers are increasingly written for it. There’s no good reason to start a greenfield project on anything else right now.
Existing Poetry project that works? Leave it alone — or migrate lazily. “It works” is a feature. Poetry is still genuinely good in 2026; it didn’t get worse because uv got faster. If your CI install time isn’t a pain point, ripping out a working Poetry setup to save a few seconds is busywork. If it is a pain point, migrate — the payoff is concrete.
Already on pip + requirements.txt and happy? You can get most of uv’s speed without committing to the whole project-manager model, which I’ll cover next. You don’t have to go all-in to benefit.
PDM users: PDM is fine, but with its signature PEP 582 feature now a dead standard, I’d struggle to recommend starting a new project on it over uv. If you’re already on it and content, no rush. For anything new, uv does what PDM does and more.
The migration nobody mentions: you don’t have to migrate
This is the part that gets lost in the “switch everything” hype. uv has a pip drop-in interface. uv pip install, uv pip compile, uv pip sync mirror the pip and pip-tools commands you already know, operating on your existing requirements.txt. No pyproject.toml rewrite, no new lockfile format, no retraining the team.
That means the lowest-risk way to adopt uv is to change exactly one thing in CI: replace pip install -r requirements.txt with uv pip install -r requirements.txt. You keep your entire existing workflow and just make the install step roughly an order of magnitude faster. If it breaks something, you revert one line. I’d start any team here — get the CI win first, decide on full project adoption later when there’s no clock running.
For a full Poetry migration, the move is to translate your pyproject.toml dependencies into uv’s project format and regenerate the lockfile with uv lock. It’s not automatic and not zero-effort — budget an afternoon and test your CI thoroughly — but it’s a one-time cost, not an ongoing tax.
A thought to leave you with
The thing I keep coming back to is that uv didn’t win by inventing a new idea. Lockfiles, project management, version pinning — Poetry and PDM did all of that first. uv won by doing the same things, in Rust, fast enough that the friction disappeared. That’s a useful reminder when you evaluate any tool: sometimes the differentiator isn’t a feature, it’s the absence of waiting.
Try the one-line CI swap on a branch this week. Watch the install time. Then decide how far down the rest of the path you want to walk.
Tooling moves fast and version numbers age quickly — check the uv docs and PyPI for current release numbers before you pin anything in production.
Sources: