uv downloads overtake Poetry for Wagtail users

Original Article ↗ Hacker News Discussion ↗

Python developers working with Wagtail and other projects are rapidly adopting uv, a new Rust-based package and environment manager, in place of tools like Poetry, pip, pyenv, and pipx. Many praise uv for its dramatic speed improvements, integrated Python version and virtualenv management, lock files, and close alignment with emerging packaging standards, which together reduce onboarding friction and dependency breakage. Others raise longer‑term concerns about relying on a corporately backed tool and note that uv still doesn’t solve all issues around native libraries, CUDA, or cross-language dependency management, where tools like conda, Pixi, Nix, or Docker may remain necessary.

Why uv is attracting so much attention

  • Viewed by many as the first time Python packaging feels “coherent”: one tool for dependency resolution, lockfiles, venvs, and Python version management.
  • Speed is repeatedly called out as transformative (10–100x faster than pip/Poetry in some reports), especially in CI, Docker builds, and on constrained hardware like Raspberry Pi.
  • Being a standalone Rust binary avoids bootstrapping issues (no “have Python to manage Python” problem) and lets it replace pip, venv, pyenv, and pipx for many users.
  • Strong support for standards (PEP-based configs, lockfiles, build backends) is seen as future-proof and makes migration away possible if ever needed.

Workflow and tooling integration

  • Users like uv init / uv add / uv run for quick one-off scripts and projects; inline script dependencies are appreciated.
  • Common pattern: keep using .venv activation directly, or automate it with fish/direnv; some prefer uv run, others find it too verbose.
  • Works with tox/nox (via plugins), PyCharm, Docker/devcontainers, Wagtail, and can act as a drop‑in pip frontend (uv pip ...).
  • Integrates with broader ecosystem tools: pyenv, mise, pixi, pdm (as a resolver backend).

Limitations and remaining hard problems

  • Does not solve non-Python/system dependency issues (CUDA, GEOS, C/C++ toolchains, system libs); people recommend pixi/conda, Spack, Nix/Guix, or Docker for full-stack environments.
  • Still relies on build backends for compiling native extensions; packages can fail to build just as with pip.
  • Not a fit for Python 2; commenters say Python 2 support is effectively over.
  • A few concrete rough edges mentioned (e.g., a uv pip install targeting the wrong venv, annoyance around extras for PyTorch/CUDA).

Ecosystem, governance, and fragmentation concerns

  • Some worry about over‑reliance on a single, corporate-backed tool (bus factor, long‑term incentives, impact on packaging standardization). Others note Astral’s active engagement with PEPs and standards as a mitigating factor.
  • There’s nostalgia and respect for pipenv, Poetry, and PDM, but several users say uv’s speed, simplicity, and flexibility make previous tools feel obsolete.
  • A minority argue pip+venv (or Poetry/PDM) “just work” for them and that retraining teams may not justify the gains, especially where pip speed isn’t a major pain point.

Wagtail‑specific observations

  • Many Wagtail projects historically used Poetry; users report it generally works but is slow and confusing for common tasks.
  • Data from Wagtail downloads show uv overtaking Poetry and PDM usage collapsing, raising concerns about betting on less‑adopted tools.