I’m excited to share a draft proposal for a PEP, which aims to introduce native support for private packages on PyPI using the existing token-based authentication system.
This PEP addresses a long-standing gap in the PyPI ecosystem by enabling developers and organizations to securely host and distribute private packages without relying on third-party services such as Artifactory or Nexus.
What this PEP proposes:
Use of PyPI’s existing token system for private package upload and download
Per-package and per-user token scopes for fine-grained access control
Seamless pip install experience for private packages using --extra-index-url
Full integration into the current PyPI infrastructure with no impact on public packages
Simplified twine support for private uploads
Foundation for future enterprise/private org package spaces on PyPI
This proposal is designed to be fully backwards compatible with existing tools and workflows, ensuring that current public packages remain unaffected.
I’m looking forward to gathering more feedback from you all to further refine the draft. If there is continued support and consensus, I intend to submit this formally to the PEPs repository soon.
PEP process note: PEP numbers aren’t assigned until there’s a draft PR which involves a finding a sponsor, and you should use NNNN until then. Let’s not use 802 for this, as it may well get assigned to another PEP.
I’ve renamed this topic, I suggest you edit the OP and .rst as well. Also I’ve moved this to the Ideas category, the PEPs is for when a draft PEP has been merged to the repo.
I believe this is already on the roadmap for PyPI Organizations.
The technical aspects of this proposal don’t seem that new and are solvable as this PEP shows. They’re important aspects, but they are an implementation detail.
PyPI is funded by donations and volunteers. How will it continue to operate if it’s being used as free storage for commercial purposes? Where does the funding come from? How does the governance work between the community led aspects and the commercial / paid storage aspects?
Clarifying: PyPI will never be providing private packages as a free service, if it does happen it will be a paid service. This is because serving private contents would jeopardize the agreements that serve all open source and community projects on PyPI currently. Private/paid services would be run on separate infrastructure.
I appreciate the enthusiasm towards this, but I think there’s a lot more to discuss before we go to a specification phase.
Particularly that the current tokens are really only scoped and intended for Uploads. Macaroons are great but in practice we’ve found them somewhat difficult to work with when bringing in new scopes (like the malware reporting API).
And generally, it’s unclear to me why a PEP is necessary to define this as a feature. The API tokens as they currently exist are merely an implementation detail of PyPI, and a design requirement for private packages/indexes is to retain compatibility with existing standards, not extend them… as many third party private indexes do.
PEP process note (2): I don’t think a PEP is appropriate for the issue as currently described – this doesn’t appear to be ecosystem co-ordination, or a change to the Repository API, but instead a specific feature request for PyPI.