#544: Wheel Next + Packaging PEPs

Summary of #544: Wheel Next + Packaging PEPs

by Michael Kennedy

1h 11m•April 10, 2026
Listen to Episode

Overview of Talk Python to Me — Episode 544: Wheel Next + Packaging PEPs

Host Michael Kennedy interviews Jonathan Decker (NVIDIA), Ralph Gommers (QuantSight / NumPy / SciPy), and Charlie Marsh (Astral / UV / PYX) about WheelNext — a cross-industry effort (NVIDIA, Astral, QuantSight, Intel, AMD, Red Hat, Meta, etc.) to modernize Python binary packaging so installers can automatically pick CPU/GPU/library-specific builds (called "variants") instead of shipping huge universal binaries or forcing users to configure special indexes.

Key topics covered

  • The problem: current wheels target a lowest-common-denominator CPU (circa 2009), losing modern CPU/GPU optimizations and forcing fat binaries + complex install instructions.
  • The solution concept: wheel "variants" — metadata + install-time resolution so package authors can publish multiple hardware-optimized binaries and installers pick the correct one automatically.
  • PEP work: large initial PEP (PEP 817) split into smaller, reviewable pieces (including PEP 825) to ease community review and adoption.
  • Implementations & prototypes: UV variant-enabled prototype, forks/branches for pip/warehouse during testing, PYX registry (Astral) to host variant builds earlier than PyPI.
  • Practical examples: NumPy’s current in-module runtime dispatch vs separate variant wheels; PyTorch size/bandwidth problem and potential savings.
  • Adoption path, trade-offs, and timelines — ecosystem-wide changes required across build backends, registries, and installers.

Problem statement (concise)

  • Wheels with compiled code only express OS/architecture/Python ABI; they do not declare:
    • CPU instruction sets used (SSE, AVX, AVX2, etc.)
    • GPU runtime/driver/CUDA compatibility
    • Linked native libraries/BLAS/GLIBC variant constraints
  • Result:
    • Wheels must be conservative → no modern CPU/GPU optimizations (huge performance loss possible)
    • Authors ship "fat" wheels containing multiple code paths/architectures or huge binaries (e.g., PyTorch ~900 MB)
    • Users must manually pick special indexes/URLs for GPU builds; installs are fragile and confusing

Proposed solution: WheelNext / wheel variants (high level)

  • Introduce metadata describing a wheel’s hardware/runtime requirements and capabilities (a generic system rather than a long list of static tags).
  • Allow package authors to publish multiple "variants" — distinct binary builds targeted at different CPU features, CUDA/driver versions, glibc versions, BLAS implementations, etc.
  • Installers (pip/UV/others) detect local hardware/runtime capabilities and resolve the optimal variant automatically.
  • Keep the platform tag system but avoid exploding it; use extensible metadata that resolvers understand or ignore.
  • Split the overall design into modular PEPs (so different parts can be reviewed/implemented independently).

Technical details and trade-offs

  • Two approaches today:
    • Runtime dispatch (NumPy): ship a combined extension with multiple backends and choose at runtime. Pros: single wheel; Cons: big binaries, complex build/test/maintenance.
    • Separate variant wheels: ship one optimized wheel per variant. Pros: smaller downloads, simpler runtime, better caching and bandwidth; Cons: more CI/builds and more variants to manage.
  • Expected gains:
    • Large performance improvements for SIMD/vectorized workloads (10–20x in some cases depending on hardware and code).
    • Major reduction in wheel sizes for projects bundling multiple architectures (e.g., PyTorch could shrink from ~900 MB to ~200–250 MB per variant).
    • Lower bandwidth and faster installs for users and registries.
  • Costs:
    • CI/build matrix expansion (more build jobs per release)
    • Need updates across the ecosystem: build backends (setuptools/pyproject tools), twine/packaging libraries, index servers (PyPI/warehouse), installers (pip/UV/poetry/etc.)
    • Slow rollout because many users run older pip versions and environments; registries and installers must be upgraded and widely adopted.

Implementations, prototypes, and related projects

  • UV (Astral): prototype variant-enabled installer; branch/fork used to test the design end-to-end. UV can already bootstrap Python via python-build-standalone and install variant-aware packages in experiments.
  • PYX (Astral): hosted package registry in beta — can host and serve variant builds earlier than full PyPI support. Waitlist available from Astral.
  • Python-build-standalone: used by UV to distribute pre-built CPython binaries; Astral has been optimizing builds for speed and distribution.
  • NumPy/SciPy: examples of existing SIMD/architecture-specific code; NumPy currently compiles multiple CPU-specific code paths and runtime-dispatches, which is complex to maintain.
  • WheelNext working group and site: wheelnext.dev — notes, participants, and drafts.
  • Community prototypes required forks/branches of pip, warehouse, installers, and build tools to validate the model.

Timeline & adoption strategy

  • PEPs are split into smaller drafts for review; at least one core PEP already in draft (community review ongoing).
  • Expected near-term: iterative prototypes and partial rollouts (provisionally accepted PEPs) and registries/third-party services adopting variants before PyPI-wide adoption.
  • Full ecosystem adoption will take longer: updates to PyPI, twine, pip, packaging libraries, and time for users to update installers.
  • Minimal-success strategy: if a handful (e.g., 5) major data-science/ML libraries adopt variants and installers support them, benefits will accumulate quickly and drive wider adoption.

How to try it / get involved

  • Read the problem primer: Ralph Gommers’ Python Packaging Native Guide (great explainer; problem-first).
  • Visit the WheelNext working group site: wheelnext.dev for drafts and contributors.
  • Try the UV experimental variant-enabled installer (Astral provides prototype builds that point at wheelnext indexes) — useful for users who want to test automatic variant selection.
  • PYX registry (astral.sh/pyx) — join the waitlist to try hosted builds and pre-built CUDA/PyTorch variants.
  • Package authors: join Python Packaging Discourse and the WheelNext discussions; test building variant wheels for your project and provide feedback.
  • Tool authors (installers, build backends, registries): engage in the PEP review and prototype implementations so change can flow fast through the ecosystem.

Notable insights & quotes

  • “We ship wheels built for CPU features from 2009” — explains why current wheels are conservative and miss modern optimizations.
  • Separating build-time variants from platform tags avoids a never-ending, unmaintainable list of static tags.
  • NumPy’s approach (building multiple code paths and runtime dispatch) works but is complex and not scalable across the wider ecosystem — variants offer a simpler path for many projects.
  • Prototype-first design + cross-company collaboration was essential: many contributors from companies and projects (NVIDIA, Meta, Intel, AMD, Red Hat, Astral, QuantSight, PyTorch, NumPy, SciPy, etc.) worked together after a March 2025 in-person summit.
  • Practical goal: make “pip install package” just work for GPU/CPU-specific needs without manual indexes or confusing install instructions.

Action items / recommendations

  • If you’re a package maintainer with heavy native code or GPU dependencies: read the WheelNext drafts and test producing variant builds in CI; join the community discussion.
  • If you’re a tooling/registry maintainer: implement or prototype resolver support for variant metadata; help validate performance and resolution behavior.
  • If you’re a user of ML/scientific packages: try the variant-enabled UV prototype or PYX-hosted builds and report UX/edge-cases to the WheelNext repo and Python Packaging Discourse.
  • Watch the PEPs and get involved early — small cohort adoption (key ML/science libs + installers) will yield outsized wins.

Further reading / links mentioned in the episode

  • WheelNext working group: wheelnext.dev
  • Astral / PYX registry info: astral.sh/pyx
  • Python Packaging Native Guide (Ralph Gommers) — excellent primer on the problem space
  • UV (Astral’s installer/project manager) and python-build-standalone (used by UV)

Summary: WheelNext aims to move Python binary packaging from a conservative single-build model to an extensible, metadata-driven variant model so installers can automatically pick hardware-optimized binaries. This promises big runtime speedups, smaller downloads, and cleaner UX for complex packages (especially ML/GPU stacks), but requires coordinated changes across build tools, installers, and registries. The working group has prototypes and invites maintainers, tool authors, and users to test and participate in the PEP review process.