How Python tools adopt uv under the hood
Several Python tools now use uv’s dependency resolver and installer as their backend. If you use pixi, Hatch, PDM, or tox, you may already be benefiting from uv without having switched to it.
Which tools use uv
| Tool | What it delegates to uv | How to enable |
|---|---|---|
| Pixi | PyPI dependency resolution and installation | Automatic (default behavior) |
| Hatch | Dependency installation and venv creation | installer = "uv" in env config |
| PDM | Dependency resolution and installation | pdm config use_uv true (experimental) |
| tox (via tox-uv) | Dependency installation and venv creation | Install the tox-uv plugin |
| nox | Dependency installation | Enable nox’s uv backend |
| prek | Python version and venv management for hooks | Automatic |
Pixi uses uv by default for all PyPI packages. Prek does the same for hook environments. The rest require opt-in configuration.
For step-by-step setup, see How to use uv to speed up Hatch and How to use uv to speed up PDM.
What parts of uv these tools use
Tools adopt uv at two layers:
Resolver. The dependency solver determines which package versions satisfy a project’s constraints. Resolving a large dependency tree is computationally expensive. Pixi and PDM delegate this work to uv’s resolver, which is significantly faster than pip’s.
Installer. The component that downloads wheels and writes them into a virtual environment. All the tools in the table above use uv’s installer, which avoids redundant work through aggressive caching and hardlinking.
These tools call uv as a subprocess. They keep their own workflow, lockfile format, environment model, and CLI. uv handles the slow, mechanical parts underneath.
Why this convergence happened
Before uv, every Python tool either reimplemented dependency resolution or shelled out to pip. Both options had costs. Reimplementing meant duplicating a hard problem (SAT solving over a package index with platform-specific metadata). Shelling out to pip meant inheriting pip’s performance characteristics and behavioral quirks.
uv’s resolver and installer are fast enough that embedding them provides an obvious improvement. A tool like Hatch can offer the same installation speed as uv without redesigning its environment matrix system or build workflow.
Python packaging standards made this swap possible. PEP 508 defines a shared dependency syntax. PEP 621 standardizes project metadata. Because tools agree on how to describe dependencies, swapping the resolver underneath doesn’t require changing the metadata format.
Astral distributes uv as a single binary with no runtime dependencies, which makes it straightforward for other tools to detect and invoke.
What this means for users
If your team uses Hatch, PDM, or tox and the workflow is working, you don’t need to migrate to uv to get its speed. Enable uv as the installer backend and the slow parts of your workflow get faster while everything else stays the same.
The ecosystem is converging on a shared fast layer with different workflow choices on top. The choice between tools is increasingly about workflow preferences (Hatch’s environment matrix, pixi’s conda support, PDM’s lockfile strategies) rather than raw installation speed.
For guidance on which tool to pick, see Which Python package manager should I use?.
Learn more
Get Python tooling updates
Subscribe to the newsletter