Rye and Uv: August Is Harvest Season for Python Packaging
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.