uv: The Fast Python Package Manager That Replaces pip, venv, pyenv and pipx

The mental model that makes uv click: it's one tool doing the job of five. Instead of learning pip *and* virtualenv *and* pyenv *and* pip-tools *and* pipx — each with its own flags and failure modes — you learn uv. Here's the mapping:

It comes from Astral, the same team that makes Ruff (the linter that already ate flake8, isort and half a dozen others — we host it as our Ruff linter tool). Same playbook: take a slow, fragmented corner of the Python toolchain and replace it with one fast Rust binary. Worth knowing for context: OpenAI acquired Astral in March 2026, so uv now sits inside a much larger company — a governance change to keep an eye on, though the tool remains open source (Apache-2.0/MIT).

Speed is the reason most people try uv, so I measured it properly. I installed the same 8 top-level packages — fastapi uvicorn sqlalchemy alembic httpx rich pydantic-settings requests, which resolve to 31 packages including transitive deps — into a fresh virtualenv each time, with both a cold cache (everything downloaded) and a warm cache (packages already local). Python 3.14.2, uv 0.12.1, pip 26.x:

=== COLD cache (purged first, network download) ===
pip :  47.26 s
uv  :   7.90 s

=== WARM cache (packages already cached) ===
pip :  36.27 s
uv  :   1.17 s
uv speedup (warm): 31.0x faster

The warm-cache number is the one that matters day to day — it's what you hit every time you rebuild a venv, run CI with a cache, or uv add a package to an existing project. 1.17 seconds to resolve and install 31 packages. Three things make uv this fast:

• A global content-addressed cache with hardlinks. uv doesn't re-copy a cached wheel into your venv — it hardlinks it. Installing an already-cached package is almost free, which is why the warm case collapses to ~1 s.
• A parallel Rust resolver. pip resolves and downloads largely serially; uv resolves the whole graph and fetches in parallel across cores. That's most of the cold-cache win.
• No per-command Python startup. pip is a Python program that pays interpreter startup and imports on every call; uv is a native binary that starts instantly.

The lowest-commitment way to adopt uv: keep your existing workflow and just put uv in front of your pip and venv commands. The interface is intentionally familiar.

# make a virtualenv (replaces `python -m venv .venv`)
uv venv

# install into it (replaces `pip install`)
uv pip install fastapi uvicorn requests

# your existing requirements.txt just works
uv pip install -r requirements.txt

# compile a lockfile (replaces pip-tools' pip-compile)
uv pip compile requirements.in -o requirements.txt

Even venv creation alone is worth it. uv venv versus the stdlib python -m venv, best of three runs:

python -m venv :   6087 ms
uv venv        :     45 ms
uv is 135x faster at creating a venv

The drop-in mode is nice, but uv's project mode is where it replaces poetry/PDM and stops you thinking about virtualenvs at all. uv init scaffolds a modern project:

$ uv init myproj
Initialized project `myproj`

$ ls -a myproj
.git  .gitignore  .python-version  README.md  pyproject.toml  src/

Then uv add installs a dependency and updates pyproject.toml, writes a cross-platform uv.lock, and syncs the project's .venv — in one step. There's no separate "create venv", "activate", "install", "freeze" dance:

$ uv add fastapi
 + fastapi==0.141.1  + pydantic==2.13.4  + starlette==1.3.1  ...
# -> wrote uv.lock (158 lines) and created .venv automatically

$ uv tree
Resolved 11 packages in 1ms
myproj v0.1.0
└── fastapi v0.141.1
    ├── pydantic v2.13.4
    │   ├── pydantic-core v2.46.4
    │   └── ...
    └── starlette v1.3.1
        └── anyio v4.14.2

$ uv run python -c "import fastapi; print(fastapi.__version__)"
0.141.1                       # ran in the project venv — no `activate` needed

Two things to notice. `uv run` never makes you activate anything — it ensures the venv is in sync with the lockfile and runs your command inside it. And the whole thing is fast enough to feel free: adding a package to the warm project took 0.35 s, and verifying the lockfile is current (uv lock --check) took 28 ms. Locking stops being a chore you skip.

This is the feature that surprised me most. uv doesn't just manage packages — it downloads and manages Python interpreters, replacing pyenv entirely. uv python list shows what's installed and what's a download away:

cpython-3.15.0b4-windows-x86_64      <download available>
cpython-3.14.6-windows-x86_64        <download available>
cpython-3.14.2-windows-x86_64        C:\...\Python314\python.exe
cpython-3.13.14-windows-x86_64       <download available>
cpython-3.12.13-windows-x86_64       <download available>
cpython-3.11.5-windows-x86_64        C:\...\Python311\python.exe

You never install a Python manually again. Ask for a version you don't have and uv fetches it on demand. I ran a command targeting 3.12 without any 3.12 on my machine — uv downloaded CPython 3.12.13 and ran on it, in 0.47 s once cached:

$ uv run --python 3.12 --no-project python -c "import sys; print(sys.version.split()[0])"
ran on 3.12.13

And it respects your project's constraints. When I tried to run my requires-python = ">=3.14" project on 3.12, uv downloaded 3.12 but then refused to run — the guardrail working exactly as it should:

$ uv run --python 3.12 python -c "..."
Using CPython 3.12.13
error: The requested interpreter resolved to Python 3.12.13, which is
incompatible with the project's Python requirement: `>=3.14`

Finally, uvx (alias for uv tool run) replaces pipx — run a CLI tool in a throwaway isolated environment without installing it into your project. Astral's own Ruff, for instance:

$ uvx ruff --version
ruff 0.16.1                    # ephemeral env, nothing added to your project

After benchmarking it, my answer is: for almost everyone, yes — but go in with eyes open. The upside is overwhelming (one tool, 30× faster, universal lockfile, no pyenv), so here are the honest reasons to hesitate:

• It's pre-1.0 and moving fast. uv is still on 0.x versioning and ships breaking changes between minors occasionally. Pin the uv version in CI (uv self version / a version file) so a surprise update doesn't change your resolves.
• `uv.lock` is uv's format, not a standard. It's excellent, but it locks you into uv for reproducible installs. uv can export to requirements.txt (and to the new PEP 751 pylock.toml) if you need an escape hatch, so this is manageable — just know the lockfile isn't portable to poetry/pip as-is.
• pip-less venvs surprise some tools. As noted, uv venv omits pip; occasionally a build script or plugin expects pip to exist in the environment. uv venv --seed fixes it.
• The OpenAI acquisition is new. Astral joined OpenAI in March 2026. The tool is open source and nothing has changed for users yet, but single-vendor control of core tooling is worth watching.

None of those outweigh a 31× speedup and the collapse of five tools into one. The migration is also low-risk because uv reads your existing requirements.txt and pyproject.toml — you can start with uv pip install today and adopt project mode whenever you're ready. If you write Python in 2026, uv is the default worth adopting.