uv — Fast Python Environments With Lockfiles

What uv is

uv is a Python package and project manager written in Rust, from Astral — the team behind the Ruff linter. It creates virtual environments, resolves and installs dependencies, manages Python versions, and produces a lockfile, all from one binary that installs without needing Python present first.

The design decision that makes it worth switching for is the lockfile. uv.lock records the exact resolved version of every direct and transitive dependency, and uv sync reconstructs that environment precisely on anyone else’s machine. Python’s traditional tooling made this optional and awkward, which is why “it worked in April” is the most common failure in computational research. uv makes the reproducible path the default path, and it happens to be dramatically faster as well.

Why researchers use it

• A lockfile you did not have to think about — uv add pandas writes it. The reproducibility artefact your paper needs is a side effect of normal work.
• Speed you notice — resolution and installation in seconds where pip took minutes, which changes whether you bother creating a clean environment for a quick test.
• One tool instead of five — it replaces pip, venv, pipx, and pyenv for most projects, including installing the Python interpreter itself.
• Drop-in pip compatibility — uv pip install -r requirements.txt works, so you can adopt it gradually without rewriting an existing project.
• Reproducible interpreter version — the Python version is pinned in the project too, closing a gap most environment files leave open.

Where it fits in a research workflow

uv sits underneath everything Python in your project, and its output — pyproject.toml plus uv.lock — belongs in the same Git repository as your analysis. That pairing is the practical definition of a reproducible Python project: someone clones the repository, runs uv sync, and has your exact environment.

It composes upward rather than competing: run Jupyter inside a uv environment, drive a Snakemake pipeline from one, render Quarto documents against one. Where it hands off is at the boundary of Python itself: the moment your stack needs CUDA, GDAL, a specific BLAS, or an R interpreter alongside, you want conda or a container. And for archival reproducibility — the “still runs in five years” standard — a lockfile is necessary but not sufficient; Docker or Apptainer captures the operating system too.

Getting started

Ten minutes, and adopt it on your next project rather than converting an old one.

1. Install with the one-line installer from the documentation. You do not need Python first — uv will fetch an interpreter for you.
2. In a new project run uv init, then uv add numpy pandas. The environment, the pyproject.toml, and the lockfile all appear without further ceremony.
3. Run things with uv run script.py rather than activating anything. It resolves the environment for you, which removes the entire class of “wrong environment activated” errors.
4. The step people skip: commit uv.lock. It is the whole point. A repository with pyproject.toml and no lockfile has recorded your intentions, not your environment.

uv vs the alternatives

For pure-Python work uv is simply better than pip and venv on every axis. The alternatives above are not competitors so much as the next layer up when Python alone is not the whole environment.

Cost, licensing, and your data

Free and open source under a permissive licence, developed by a venture-funded company (Astral) that also produces Ruff. That funding model is worth naming: the tool is genuinely open and forkable, but its long-term direction depends on a company that will eventually need revenue. The lockfile format is documented and the tool is drop-in compatible with standard Python packaging, so the exit cost is low — which is the reassurance that matters.

There is no service, no account, and no data leaving your machine beyond package downloads from PyPI, so there is nothing to weigh on governance grounds.

The honest review

Strengths. uv is the rare tool that is better on every axis at once for its core use case — faster, stricter, simpler, and compatible with what came before. The speed is not a vanity metric: when creating a fresh environment costs two seconds instead of two minutes, you start doing it, and casual environment hygiene is worth more to reproducibility than any single feature.

Limitations. It is young, and edge cases still surface — unusual build backends, packages with awkward native extensions, and occasional differences from pip’s resolution behaviour on tangled dependency trees. It manages Python and nothing else, so a stack needing CUDA or GDAL still pushes you to conda or containers. The rapid release cadence that makes it improve quickly also means behaviour occasionally changes between versions. And its long-term stewardship rests with a company rather than a foundation.

Verdict. Adopt it for any new pure-Python project — there is no longer a good reason to start one with bare pip. Skip it if your stack is dominated by non-Python binaries, or if your institution’s tooling is standardised on conda and you would be swimming upstream. The condition that flips the answer is what is underneath your packages: pure Python, uv; C libraries and CUDA, conda or a container.

Common questions

Is uv free?

Yes, free and open source under a permissive licence. It is developed by Astral, a commercial company, but the tool itself has no paid tier and no account.

Can uv replace conda?

For pure-Python projects, yes — and it is faster and simpler. For anything needing non-Python binaries such as CUDA, GDAL, compilers, or an R interpreter, no: that is exactly what conda exists for, and uv does not attempt it.

Should I switch an existing project to uv?

Adopt it on your next project rather than converting a working one mid-analysis. If you do want to migrate, uv pip install -r requirements.txt works as a drop-in first step, letting you get the speed benefit before committing to pyproject.toml and a lockfile.