A year of uv: pros, cons, and should you migrate

Overall sentiment

• Many commenters are extremely positive: uv is described as the first Python tool in years that “just works”, feels fast, and meaningfully reduces packaging pain.
• Some are skeptical or indifferent, preferring existing setups (conda+mamba, pip+venv, poetry) or wary of yet another “fix everything” tool that may not last.

Key benefits users highlight

• Very fast dependency resolution and installation, including as a drop‑in replacement for pip install -r requirements.txt.
• Automatic management of Python versions and virtual environments, so users (especially non‑Python devs and scientists) can often ignore venv activation entirely.
• Project‑centric workflow with lockfiles and good reproducibility; works well alongside Docker (often used inside images).
• Support for dependency overrides and multiple indexes, including PyTorch wheels, extra indexes (e.g. NVIDIA, custom PyPI mirrors), and platform‑specific indices.
• Inline script metadata via PEP 723 and uv run shebangs makes one‑off scripts and demos much easier to share and reproduce.

Pain points and missing features

• Harder onboarding for legacy or messy projects with many in‑house packages and conflicting constraints; uv can be more strict than pip and lacks a “just warn” mode.
• No seamless equivalent to long‑lived shared conda environments or a centralized “global venv” workflow; project‑per‑venv doesn’t match everyone’s habits.
• Some workflows (Django management commands, interactive use, “non‑project” notebooks) still benefit from explicit venv activation that uv doesn’t fully replace.
• Issues behind corporate proxies and with tools that abuse pip internals (e.g. packages that self‑modify pip configuration).
• GitHub Dependabot and some IDEs don’t yet fully understand uv lockfiles or inline dependency metadata.

Comparisons with other tools

• Versus Docker: Docker gives OS‑level reproducibility but is clumsy as a primary dependency manager; many now combine Docker with uv.
• Versus conda/mamba/micromamba: conda already solves cross‑platform Python and non‑Python deps, but is seen as slow, complex, and license‑encumbered; uv is leaner and more pleasant for pure‑Python and typical app dev.
• Versus poetry/pipenv/rye: uv is perceived as faster, more standards‑aligned, and less opinionated about build backends; rye is effectively being superseded by uv.

Dependency resolution, overrides, and lockfiles

• Lengthy debate over whether tools should let users override transitive dependency constraints; other ecosystems (npm, yarn, cargo, Maven, SBT) generally do, Poetry mostly doesn’t, uv does.
• Discussion of Python’s fragile metadata (can’t retroactively update constraints), the need for robust lockfiles, and ongoing standardization via PEP 751.
• Some argue lockfiles are for reproducible builds only; others use them as essential shields against upstream breakage, especially for older projects.

Performance, caching, and heavy dependencies

• Huge caches (tens of GB) for PyTorch and CUDA/ROCm remain a problem; uv mitigates duplication with hardlinks and offers uv cache prune/clean, but cannot fix upstream wheel bloat or per‑Python ABI differences.
• Comparisons with Nix‑style deduplication and filesystem‑level tricks (ZFS/Btrfs reflinks) appear, but most see this as outside uv’s core scope.

Business model, naming, and culture

• Curiosity and mild concern about Astral’s monetization; speculation that they may target Anaconda‑like B2B offerings, with some fear of Docker‑style licensing shifts.
• Some confusion and annoyance over the name “uv” given existing libuv/uvloop/UV‑ray associations.
• A few commenters frame Python’s packaging woes as cultural (too many tiny deps, frequent breaking changes), while others note that modern Python packaging is now good enough to be envied by other ecosystems, with uv accelerating that trend.