Rye and Uv: August Is Harvest Season for Python Packaging
Python’s long‑standing packaging and dependency woes are again in focus as new tools like uv (inspired by Rye) promise faster installs, workspace support, and a more “cargo‑like” experience. Commenters weigh the appeal of consolidating on a single, high‑performance tool against concerns over PyPA’s role, governance and “official” endorsement, and the risks of relying on a VC‑backed company for core ecosystem infrastructure. Others note that while uv brings clear speed and ergonomics gains, deeper issues—such as virtualenv complexity, monorepo support, binary distribution, and native/CUDA dependencies—remain only partially solved.
uv, Rye, and “one tool to win”
- Many welcome uv’s rapid progress and Rye’s role as a prototype feeding into it.
- Desire for a “one tool wins” experience similar to cargo is strong, especially to avoid time lost on venvs, PYTHONPATH, and monorepos.
- Some find migrating from poetry to uv harder than expected; others report seamless moves from pip-tools and praise uv’s speed and workspace support.
- There is confusion about whether Rye is effectively deprecated; consensus is “use uv” going forward.
Authority, PyPA, and standardization
- Several comments argue Python lacks a single endorsed, integrated tool like Rust’s cargo.
- PyPA is seen by some as technically valuable but politically messy, slow, or misprioritized; others note solid tools under its umbrella (e.g. pipx).
- Some think Python core/PSF endorsement (official tutorial recommending a tool) would matter more than PyPA’s.
Technical critiques of Python packaging
- Long, detailed criticism: wheel format discouraging precompiled bytecode; compilation at import time causing permission issues and workarounds; fragile dependency resolution rules (URLs as deps, auto-building sdists, version-mismatch risks); and an import system that can’t express package versions, forcing virtualenvs.
- Alternative designs are proposed (e.g., multiple versions coexisting in one install with metadata-driven resolution), but are hypothetical.
Performance and scale
- uv is credited with massive speedups in large projects (e.g., release process time dropping from hours to minutes).
- pip performance has reportedly improved significantly recently, but legacy design constraints and complex dependency graphs remain a drag.
Monorepos and dependency management
- Python monorepos are described as “hell”; people write custom plugins/scripts or eye uv workspaces and Bazel-style approaches.
- FAANG-style “one version of each dependency, vendored and maintained” is acknowledged as effective but labor-intensive and hard to replicate without large teams.
Governance, corporations, and VC
- Strong mistrust of VC-backed control over critical tooling (npm/Microsoft history cited).
- Some argue Python is already heavily influenced by large companies; others push back or see it as shared among multiple corporate and individual stakeholders.
- Forkability of uv is seen as both a safety valve and a potential source of future fragmentation.
Alternatives and deployment
- Nix (and sometimes Bazel/buck2) is proposed as a more general, language-agnostic answer, but others report poor real-world Python dependency experience.
- For CUDA/JAX and conda-based workflows, uv is seen as insufficient; pixi/mamba are suggested instead.
- Several participants say their real pain is not package management but building self-contained, shippable executables; uv/related work may help but doesn’t fully solve this yet.