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.