mrkeyoor.com_
Thu 01 Oct 01:35 UTC
Dev Toolsevaluationupdated 27 Aug 2026

uv review

uv is a Rust-built command-line tool for Python environments, dependencies, lockfiles, scripts, tools, Python installations, builds, and publishing. It reduces the number of separate utilities a Python developer needs while offering a familiar `uv pip` interface for common pip workflows.

+141stars / 7d
Verdict

Our uv source run built in 4 seconds and pip-audit found 0 known vulnerabilities, but pytest stopped after 5 seconds with 3 setup errors before any test passed. Existing projects should migrate in a branch and compare lockfiles, install outputs, indexes, editable packages, and CI behavior before switching. The current archive-verification work deserves attention from high-assurance build pipelines, even though our dependency audit found no known vulnerabilities.

We ran it

Lab card: what happened when we ran uvScreenshot of uv (docs.astral.sh/uv)
Install✓ · 414s33 packages · 163 MB
Build✓ · 4s
Tests✗ · 5s0 passed · 0 failed · 3 errors of 3 (pytest)
Known vulns0(pip-audit)
Repo1701 files~533,676 lines of source · 39.6 MB · 41 CI workflows · Dockerfile · tests dir

Answers from our run

Does uv build from source?

Dependencies installed in 414 seconds (33 packages), and the build succeeded in 4 seconds. We cloned commit 26a9dd4 into a clean Debian container with 3 CPUs and no project-specific setup.

Do uv's tests pass?

Yes: 0 of 3 passed when we ran the project's own test command (pytest), with 3 collection errors. Some failures need services or credentials a bare container does not have.

Does uv have known vulnerabilities in its dependencies?

pip-audit found none in the dependency tree at the time of our run.

Who should not use uv?

Teams that require every pip command and edge case to behave identically: the README promises compatibility for common uv pip workflows, not a complete pip reimplementation.

What are the alternatives to uv?

Poetry, PDM, pip-tools. Our uv source run built in 4 seconds and pip-audit found 0 known vulnerabilities, but pytest stopped after 5 seconds with 3 setup errors before any test passed.

Setup5/5Standalone binaries work without Python or Rust
Docs5/5Strong guides and references across the full project workflow
Community5/5Current releases, daily changes, and active issue handling
Maturity4/5Production-ready core with important security edge work still open

Discussed on

  1. hnuv: An extremely fast Python package and project manager, written in Rust753 points
  2. hnWarn about PyPy being unmaintained326 points
  3. hnuv: Deduplicate all files in the wheel cache231 points
  4. hnUv 0.12.0131 points
  5. hnYou can now uv run a GitHub gist33 points

Who it’s for

Python teams that want one fast tool for environments, locking, dependency sync, scripts, and command-line packages.
Projects that value a cross-platform lockfile and reproducible uv sync behavior.
Developers replacing combinations of pip, pip-tools, pipx, virtualenv, pyenv, Poetry, or Rye.
CI maintainers who can pin uv and review lockfile changes as part of dependency updates.

Who it’s NOT for

Teams that require every pip command and edge case to behave identically: the README promises compatibility for common uv pip workflows, not a complete pip reimplementation.
Security-sensitive builders assuming a lockfile hash is always checked before source code runs: open pull request 21223 says a replaced source archive can reach its build backend before a later rejection.
Projects expecting uv sync --upgrade to refresh every transitive build dependency automatically: issue 21273 reports setuptools remaining pinned despite upgrade requests.
CI configurations that use 3.x to mean the newest stable Python: issue 21274 documents that uv rejects that request form and may reuse any satisfying major version.
Contributors looking for a small Python codebase: the repository is a large Rust project, and our generic pytest path did not collect cleanly.

Setup reality

Our source-path install succeeded in 414 seconds, adding 33 packages and using 163 MB on disk. The build succeeded in 4 seconds. Pytest stopped after 5 seconds with 0 passed, 0 failed, and 3 collection or setup errors; the log tail shows ModuleNotFoundError: No module named 'keyring'. A pip audit found 0 known vulnerabilities.

Ordinary users do not need this source setup. Astral supplies standalone installers and binaries for macOS, Linux, and Windows, plus a PyPI package. uv can download Python itself, so a system Python or Rust toolchain is not required for the normal install.

Migration still changes project files and behavior: teams must decide whether to adopt uv.lock, how to configure indexes and credentials, which Python versions to pin, and where CI caches live. Preview features should be enabled deliberately rather than copied into a production workflow unnoticed.

Python packaging under one command

uv combines jobs that Python projects have traditionally split across several tools. It can create a project, resolve and lock dependencies, build a virtual environment, synchronize it, run commands, execute one-file scripts with inline metadata, install command-line tools, download Python interpreters, build distributions, and publish them. The binary is written in Rust, but normal users do not need Rust or even an existing Python installation.

That consolidation is the reason to consider uv. A new contributor can install one executable, run uv sync, and receive the Python version and environment described by the project. Tool execution through uvx replaces many pipx uses, while uv pip gives established requirements-file projects a gentler migration path. Workspaces cover repositories with several related packages.

The replacement claim needs some restraint. Python packaging has years of special cases involving indexes, editable installs, build backends, platform markers, credentials, and old setup conventions. uv covers a broad portion of that work, but teams should test the parts they depend on rather than assuming every pip or Poetry detail transfers unchanged.

What happened when we ran it

We cloned commit 26a9dd4 into a fresh, unprivileged Python 3.12 Bookworm container with three CPUs, 8 GB of RAM, and no secrets. The checkout contained 1,701 files, about 533,676 lines of source, and occupied 39.6 MB.

The selected install step succeeded in 414 seconds. It added 33 packages using 163 MB on disk. The build succeeded in 4 seconds, and pip-audit found 0 known vulnerabilities. The repository has 41 CI workflow files, a Dockerfile, and a tests directory.

Pytest failed after 5 seconds with exit code 1. It reported 0 passed, 0 failed, and 3 collection or setup errors. The final trace shows test/packages/keyring_test_plugin/keyrings/test_keyring.py importing keyring, followed by ModuleNotFoundError: No module named 'keyring'. The summary also names publish and package fixture tests among the three errors. This means our generic Python test command did not assemble the repository's required test environment; it does not show a failing uv behavior assertion.

Installing the product is far easier than building the repository

Astral provides shell and PowerShell installers, a PyPI package, and prebuilt release archives across common desktop and server platforms. Standalone installations can update themselves. Release 0.12.6 also publishes checksums and GitHub artifact attestations, with verification commands in the release notes. That gives security-conscious teams a better path than piping an installer straight into a shell without inspection.

Once installed, uv can fetch managed Python builds and pin a version in the project. uv init, uv add, uv lock, uv sync, and uv run form a coherent daily loop. A global cache deduplicates downloaded and built artifacts across environments. The README publishes performance comparisons, but our lab did not reproduce those benchmarks, so our recommendation rests on workflow coverage and the measured source checks above, not a speed claim.

Adoption still deserves a branch. Generate the lockfile, compare resolved versions with the existing environment, check editable installs and optional groups, then run the application's own test suite. CI should pin uv rather than silently following the newest release, especially when a lockfile or resolver change could alter the environment.

Indexes, upgrades, and version requests have edges

Private indexes combine configuration and credential handling. Release 0.12.6 fixed credential reuse during tool upgrades when a receipt points at the same configured index. Teams should still avoid putting secrets in tool receipts. Teams should test authentication for sync, tool install, and tool upgrade separately because they may follow different paths.

Upgrade intent also needs inspection. Issue 21273 reports that uv sync --upgrade, including a highest-resolution request, left a transitive setuptools pin unchanged. The exact resolver reasoning matters, but the practical lesson is simple: review the lockfile diff and run a dependency scanner instead of treating an upgrade command as proof that every indirect package moved.

Python selection is similarly precise rather than magical. Issue 21274 asks for the 3.x convention used by another CI action. The report says uv rejects that syntax, while a bare major version may reuse an already installed interpreter instead of fetching the newest minor. Pinning an exact supported line is clearer for repeatable CI anyway.

Supply-chain details deserve close review

uv records hashes in its lockfile and isolates builds, both useful foundations. Open pull request 21223 identifies a sharper edge: when resolving from an existing lockfile, a replaced source archive could provide build metadata before its recorded digest was compared, with rejection happening later. Related pull requests split archive validation from cache persistence and add earlier checks.

That work is active rather than theoretical cleanup. Build backends execute code, so verification order matters for hostile or replaced source archives. High-assurance environments should follow those changes, verify which release contains the fix, prefer trusted indexes and wheels where policy allows, and keep network and credential exposure limited during builds.

Health and the recommendation

The repository was pushed on August 27, 2026. Release 0.12.6 arrived on August 25 with Python build updates, cache accounting changes, profile-guided binaries, and fixes for Git pins, recursive extras, and index credentials. GitHub showed 2,854 open issues and pull requests, while August 27 work covered Python markers and new target platforms. The queue is huge, but the activity is immediate and detailed.

For a new Python service or library, uv is the first project manager I would trial. For an established build, its value is still strong, but migration should be proven against the project's oddest dependency and index cases. Keep the old lock and CI path available until uv reproduces the environment you intend, not merely one that installs successfully.

Alternatives

ProjectWhat it isPick it when
Poetry gh↗A Python dependency and packaging tool with environments, locking, building, and publishing.pick this instead when your team already uses Poetry's project model and plugin ecosystem and sees no reason to migrate.
PDMA standards-focused Python project manager with locking, scripts, workspaces, and multiple environment modes.pick this instead when PEP-centered configuration and PDM's workflow fit better than uv's all-in-one CLI.
pip-toolsA narrow pair of commands for compiling and syncing pinned pip requirements.pick this instead when the project wants conventional virtualenv and pip behavior with only a small locking layer.

What people are saying

  1. [velocity-scout] astral-sh/uv

Sources

  1. uv README
  2. uv 0.12.6 release
  3. Pull request 21223: locked source archive verification
  4. Issue 21273: transitive dependency upgrade
  5. Issue 21274: latest Python request semantics

More dev tools reviews

gander · lipgloss · roundhouse · GhostTrack · Codex-Dream-Skin · TokenTracker · the whole board →