TL;DR: uv is Astral’s Rust-written Python tool (same team as Ruff) that folds pip, venv, pyenv, and pipx into one command. uv add installs, uv run runs, uv python install manages versions, and it creates the .venv for you on first use. Installs land roughly 8–10x faster than pip on a cold cache, and near-instant on a warm one. It’s command-compatible with your existing requirements.txt, so trying it on one project costs almost nothing.

Spinning up a new Python project means keeping a small pile of tools in your head. venv for the environment, pip for packages, requirements.txt for dependencies, pyenv if you care about the interpreter version, pipx for installing a CLI globally, and poetry or pip-tools once you want real lockfiles. Each one is fine on its own. Together they’re a mental lookup table you re-run every time you start: which job goes to which tool.

uv is the thing that cleared that table for me. One command took over almost the whole row.

What it actually replaces

Here’s the rough translation, old habit on the left, the uv version on the right:

Used to be With uv
python -m venv .venv then source it nothing to do — uv creates .venv on first run
pip install requests uv add requests
pip install -r requirements.txt uv pip install -r requirements.txt (compatible)
python script.py uv run script.py (runs in the right env automatically)
pyenv install 3.12 uv python install 3.12
pipx run black uvx black
poetry lockfiles and publishing uv (pyproject.toml + uv.lock)

A few of these are worth slowing down on. The first time uv add runs in a folder, it builds the virtual environment and writes the dependency into pyproject.toml for you. There’s no activate step to remember, because uv run finds the environment and runs inside it. uvx is shorthand for uv tool run: it spins up a throwaway environment, runs a CLI tool, and tears it down. That’s exactly pipx’s job. Version management is built in too. uv python install 3.12 fetches an interpreter directly, so pyenv drops out of the picture.

One detail matters more than it sounds: uv is a single binary, and installing it doesn’t need an existing Python. That kills the chicken-and-egg problem pyenv always had: you needed a Python to manage your Pythons.

How much faster, really

Speed is uv’s loudest selling point, and it’s the Rust kind of fast. Downloads run in parallel; fetching metadata, resolving dependencies, and writing to disk overlap instead of queuing. pip downloads sequentially by default and leans on multiple processes to get around Python’s GIL, which adds overhead. The gap shows up fast.

Some concrete numbers. Installing something like JupyterLab, pip clocks about 21 seconds and uv about 2.6 — call it 8x. On a warm cache, where the packages are already on your machine, uv rebuilds the environment with hardlinks and the speedup gets silly: rebuilding a couple dozen packages, pip takes several seconds, uv finishes in a fraction of one.

Astral’s headline figure is “10–100x faster.” I read that as honest, as long as you read the range: the ~100x end is warm-cache environment rebuilds, and the everyday case (a fresh, uncached install) lands closer to 8–10x in independent tests. Even at the bottom of that range it adds up, especially in CI, where every run reinstalls from scratch. For what it’s worth, by April 2026 uv was pulling around 75 million monthly downloads on PyPI, past Poetry, and turning into a default in CI setups.

The part that surprised me

After a while, speed stopped being the thing I noticed. What I noticed was that the mental table was gone.

I used to sort tasks by tool without thinking — environment goes to venv, installing goes to pip, versions to pyenv, global tools to pipx. Now it’s mostly uv followed by whatever I’m trying to do. What disappeared wasn’t a few seconds; it was the small tax of laying out the toolchain in my head at the start of every project. It’s the same thing I noticed about coding agents moving back to the terminal: the best tools earn their keep by what they let you stop tracking.

So, switch or not

I’m not going to tell you to drop everything and convert — that reads like a sales pitch. The honest version: plain pip / venv projects move over almost painlessly, because uv mirrors pip’s own command surface. uv pip install -r requirements.txt runs as you’d expect, so you can test the water with commands you already know.

The one place to watch is the conda world. Scientific computing that pulls in a stack of non-Python binaries (the C and Fortran libraries conda packages up for you) isn’t a painless port, and conda still earns its keep there. If you’re a pip person, try it freely. If you live in conda, don’t rush.

Trying it on one project

The installer is a one-line script from the docs (curl ... | sh on macOS / Linux, a PowerShell line on Windows), and it’s also on Homebrew, winget, and pipx if you’d rather. Once it’s in, don’t renovate everything at once — pick one existing project:

# inside the project, install against the existing requirements.txt
uv venv
uv pip install -r requirements.txt

# or start using uv's own project management
uv init
uv add requests
uv run python main.py

Run it a few times and feel the difference: no activate step, and installs fast enough to be mildly disorienting. Like it, and you can roll it out to other projects slowly. It won’t force an all-at-once migration.

uv didn’t invent any new ideas. Virtual environments, lockfiles, version management: Python has done all of these for years. What it did was gather the scattered tools behind one entry point and put Rust under the speed. That’s the whole thing. Day to day, that’s plenty.

Related reading:

For the source: uv official docs, astral-sh/uv on GitHub.

Chinese version: uv 是什麼？把 pip、venv、pyenv 收進一個指令