PYX: The next step in Python packaging

Original Article ↗ Hacker News Discussion ↗

What pyx Is Intended To Be

  • Described as a private Python package registry/service, not a client tool.
  • Speaks standard PyPI protocols (PEP 503/691) so pip/uv can talk to it; positioned more as “private PyPI / Artifactory-like service” than as a public index.
  • Aimed at multi-package projects, private packages, and corporate workflows that PyPI doesn’t cover.

GPU / Native Dependencies Focus

  • Big selling point is handling PyTorch, CUDA, and similar GPU-heavy stacks without users wrestling with compiler toolchains.
  • Idea: curated indices per accelerator (CUDA/ROCm/CPU), with prebuilt, mutually compatible artifacts across OS, Python versions, and library versions.
  • uv can already auto-select a PyTorch backend based on local hardware; pyx extends this with richer curated registries and metadata.
  • Some discussion about future support for describing target hardware (e.g., dump hardware on a cluster node, build elsewhere).

Metadata, Index APIs, and Performance

  • PyPI’s “simple index as URLs” model criticized for weak metadata, lack of reverse-dependency queries, and need to download wheels just to inspect them.
  • pyx is said to provide “uv-native metadata APIs” and use newer standards (e.g., PEP 658) to allow faster resolution, dry runs, and parallel installs.
  • There’s debate over how much of this is fundamentally blocked by PyPI versus by pip’s aging internals and scarce maintainer resources.

Business Model, VC, and Trust

  • Many comments see pyx as the long-expected commercial piece behind Astral’s OSS tools (uv, Ruff, etc.).
  • Strategy: tools stay free and permissively licensed; revenue comes from hosted services like pyx.
  • Some welcome a clear, sustainable model; others fear the usual VC pattern: acquisition, feature removal, or license changes, and worry about OSS projects competing with internal SaaS.
  • Counterpoints note permissive licenses and forking as safety valves, but skepticism about investor pressure remains strong.

Overlap with Existing Solutions

  • Comparisons to conda/anaconda, conda-forge, EasyBuild/Spack, Nix/uv2nix, Artifactory, Nexus, CRAN, npm.
  • Some argue “problems are already solved” with venv+pip or distro packages; others point to ongoing pain with compiled extensions, CUDA stacks, and cross-platform builds.
  • Several see pyx as directly competing with private registries (JFrog, CodeArtifact, GitHub Packages) rather than PyPI itself.

Fragmentation, Naming, and Ecosystem Fatigue

  • Many express fatigue at “yet another” Python packaging thing, joke about XKCD 927/1987, and lament Python’s many tools versus “one obvious way.”
  • Others counter that standards (pyproject.toml, build backends, metadata PEPs) deliberately enable competing tools like uv/pyx.
  • Minor controversy over the name “pyx” (already a Cython extension and an existing PyX project), seen by some as unnecessarily confusing.