Why doesn't Python just fix packaging?
If you’ve come to Python from Go, Rust, or even JavaScript, you’ve probably had this thought: why are there so many competing tools for something as basic as installing packages? Go has go mod. Rust has cargo. Why can’t Python just pick one and ship it?
The short answer: the people who could do it have chosen not to, for reasons that make more sense once you see how Python is organized.
A federation, not a kingdom
Python looks like one thing from the outside, but it’s governed by several independent groups with overlapping but distinct responsibilities:
| Entity | Controls | Doesn’t control |
|---|---|---|
| Steering Council | CPython language and standard library | Packaging tools, PyPI |
| PSF | Trademarks, infrastructure funding, PyCon | Technical decisions about the language or its tools |
| PyPA | pip, setuptools, twine, the Packaging User Guide | The language, the standard library, third-party tools like uv or Poetry |
| Core developers | The CPython codebase | What tools people use to install packages |
| PyPI | The package repository | How packages are built or installed locally |
No row in that table covers the full packaging experience. The Steering Council could add a package manager to the standard library. They have the authority. But they’ve deliberately chosen not to go beyond the minimal ensurepip bootstrap, because anything added to the stdlib moves slowly and is hard to change. The PSF could fund a unified packaging effort, but it’s a small non-profit (roughly a dozen paid staff) focused on infrastructure, not software direction. PyPA maintains pip, but it’s a volunteer working group that explicitly avoids adding things to the standard library.
The result is that packaging lives in the gaps between these organizations. Not because nobody can own it, but because each group has decided it falls outside their scope. Core developer Brett Cannon put it bluntly: “They’re separate because Guido doesn’t care about packaging. That’s really what it comes down to.” Packaging knowledge didn’t earn anyone a spot as a core dev, so the community filled the void with its own tools, and separate groups took ownership.
Compare this to languages that “just work”
In Rust, the core team and Cargo team are both part of the Rust Project. Cargo ships with every Rust installation. One organization controls the language, the package manager, and the registry.
In Go, go mod is built and maintained by the Go team at Google. One team, one tool, one decision-maker.
Python’s packaging tools developed outside the core language project. distutils shipped with CPython in 2000 but proved inadequate. setuptools replaced it as the de facto standard without ever being officially adopted. pip became the default installer through the same informal path. By the time anyone thought about unifying things, the ecosystem had already fragmented across multiple tools maintained by different groups with different priorities.
Standards instead of tools
Rather than picking a winner, Python’s approach has been to define interoperability standards through PEPs. PEP 517 and PEP 518 defined how build tools should interface with installers. PEP 621 standardized project metadata in pyproject.toml. PEP 751 defines a standard lockfile format.
This standards-based approach is why tools like uv, Hatch, PDM, and Poetry can all coexist: they implement the same standards and produce compatible artifacts. It also means that a better tool can emerge without needing permission from a central authority — which is exactly how uv happened.
The tradeoff is that nobody gets to say “use this one.” New Python users face a confusing landscape of choices that Go and Rust developers never have to think about.
The Packaging Council
In April 2026, PEP 772 created a formal Packaging Council: five elected members with authority over packaging standards and the Packaging User Guide. This gives the standards process a permanent, elected home for the first time, replacing ad-hoc delegations from the Steering Council to individual volunteers.
The council doesn’t collapse the table above into a single row. The Steering Council still owns the language, the PSF still funds infrastructure, and PyPA still maintains pip and setuptools. But packaging standards decisions now go through a dedicated body with elected accountability, rather than depending on whichever individual happened to hold a standing delegation.
Note
uv is the handbook’s recommended package manager.