Uv is the best thing to happen to the Python ecosystem in a decade

Original Article ↗ Hacker News Discussion ↗

Many Python developers see the new Rust-based tool uv as a long-awaited fix for the language’s fragmented, slow, and error‑prone packaging and environment story, praising its speed, unified workflow, and ability to manage Python versions, virtual environments, and lockfiles in one place. Others are more cautious, arguing that existing tools (pip, venv, conda, poetry) are “good enough,” raising concerns about security practices like curl‑piping install scripts, and questioning the long‑term implications of relying on VC‑backed companies such as Astral for core tooling. The broader thread reflects both relief that Python now has npm/cargo‑style ergonomics and anxiety about ongoing ecosystem churn, reproducibility, and how to handle non‑Python system dependencies.

Role of uv vs existing tools

  • Many see uv as the “npm/cargo/bundler” Python never had: one fast, unified tool instead of pip + venv + pyenv + pipx + poetry/pipenv.
  • Others argue the same concepts existed (poetry, pip-tools, pipenv, conda) and uv is mainly a better implementation with superior ergonomics and performance.
  • Some prefer minimalism (plain python -m venv + pip) and feel uv mostly repackages workflows they never found painful.

Perceived benefits

  • Speed is repeatedly called out: dependency resolution, installation, and reuse from cache feel 10–100x faster than pip/conda/poetry.
  • “Batteries-included” workflow: uv init / add / sync / run handles Python version, venv, locking, and execution without manual activation.
  • Inline script metadata (PEP 723) + uv run makes single-file scripts self-contained and shareable without explicit setup.
  • Good fit for beginners, non-engineers, and “I don’t want to think about environments” users; reduces the biannual “debug Python env day.”
  • For some, uv finally makes Python pleasant again compared to ecosystems with strong tooling (Node, Rust, Ruby).

Security & installation debates

  • Strong pushback on curl | sh / iwr | iex install instructions: seen as unsafe, unauditable, and bad practice in 2025.
  • Counter-arguments: installing unsigned .deb/.rpm is not inherently safer; trust in source matters either way; scripts can be downloaded and inspected.
  • Similar concern about scripts that auto-install dependencies at runtime: convenient but expands the attack surface unless constrained to trusted indexes/mirrors.

Limits, pain points, and skepticism

  • Some report uv failing where plain venv+pip worked, and note it’s still young with rough edges.
  • Complaints: “does too many things,” confusion around new env vars, perceived friction with Docker, lack of global/shell auto-activation, project-centric mindset vs “sandbox” global envs.
  • A few hit specific bugs (e.g., resolving local wheels, exotic dependency constraints) and still keep poetry or pip+venv.

Conda, CUDA, and non-Python deps

  • Consensus: uv is excellent for pure-Python; conda (or pixi, which uses uv under the hood) still wins for complex native stacks (CUDA, MPI, C/C++ toolchains, cross-OS binary compatibility).
  • Some hope uv (or pixi+uv) will eventually reduce reliance on conda, especially in ML/scientific environments, but that’s not solved yet.

Ecosystem, governance, and fragmentation

  • Debate over a VC-backed company steering core tooling: some see risk of future “Broadcom moment,” others point to MIT licensing and forking as safety valves.
  • Harsh criticism of PyPA’s historic decisions and the long-standing packaging “garbage fire”; uv (and Ruff) are seen as proof that fast Rust-based tools can reset expectations.
  • Fragmentation (pip, poetry, conda, uv, pixi, etc.) is still viewed as a barrier for newcomers, even if uv is emerging as a de facto standard for many.