Use of PyPI as a generic storage platform for binaries

Thanks everyone for this thoughtful discussion. Speaking as PSF Board Chair, I want to acknowledge the importance of this topic.

The PSF has a clear mission, and PyPI exists to serve that mission. As Ee rightly pointed out, this is not just colloquial but a real fiduciary and legal obligation. The PSF’s sponsors generously support PyPI as infrastructure for the Python ecosystem, and we owe it to them and to the community to be thoughtful stewards of that trust.

At the same time, I want to acknowledge that this is genuinely hard to draw a bright line around. There is a well-established history of packages on PyPI that wrap non-Python tools to serve Python development workflows. Build tools like cmake, compilers like ziglang, and linters like cpplint are real, practical examples. Nobody seriously disputes their value to the Python community. The question is what happens when that pattern is generalized into a distribution mechanism for software that has no meaningful connection to Python, and where mature, purpose-built distribution channels already exist in the software’s native ecosystem.

I share the concerns raised about sustainability. PyPI’s operational costs (storage, bandwidth, support, and the human effort of maintaining the software) are covered by the PSF and its sponsors. Encouraging the use of PyPI as a general-purpose CDN for arbitrary binaries, particularly from ecosystems that already have well-funded distribution infrastructure of their own, is not something we should take lightly. The Go module ecosystem, for example, has approximately 2.5x more packages than PyPI and is backed by significant resources.

Donald’s framing is a good starting point: if there is a clear, practical benefit to Python users and developers, that has historically been and should remain acceptable. If someone is simply looking for a convenient place to host binaries unrelated to Python, that falls outside what PyPI is for.

We recognize that the existing Acceptable Use Policy and Terms of Service could be clearer on this point. We are actively looking at this at the Board and organizational level, and our goal is to arrive at a well-considered policy that provides clearer guidance to both publishers and PyPI administrators. Given the range of opinions here and the potential impact on existing packages, we want to get community input as part of that process.

In the meantime, I would encourage publishers to consider whether PyPI is genuinely the right distribution channel for their software, or whether their users and the broader ecosystem would be better served by publishing through the tools and registries designed for their language. The conda OSS ecosystem (including tools like pixi) and language-native registries are purpose-built for cross-language and binary distribution and deserve serious consideration.

15 Likes