[Distutils] RFC: PEP 541 - Package Index Name Retention
ncoghlan at gmail.com
Sat Jan 14 03:04:45 EST 2017
Regarding reachability: contact attempts should also include the
relevant project's issue tracker if attempts at private contact have
This step is important as it allows a project's *user* community to
respond, even if the person that actually pushes the buttons to upload
new releases to PyPI is out of contact for some reason.
On 14 January 2017 at 05:13, M.-A. Lemburg <mal at egenix.com> wrote:
> Likewise, a trademark owner should be able to reserve project
> names with the trademark to avoid any such issues to begin with,
> e.g. https://pypi.python.org/pypi/Python is such a project :-)
We also have at least one case where we've reserved a name
indefinitely because it's shipped as part of another popular project.
Specifically, Donald is the owner of pkg_resources so we can ensure
that "pip install pkg_resources" is an error, rather than silently
installing the wrong thing.
The only projects we'd release that name for are either setuptools
splitting out pkg_resources as a separately installable component, or
else a shim endorsed by Jason as the lead setuptools maintainer that
installed setuptools as a dependency (see
>From a policy perspective, I think the kind of phrasing I'd be looking
for would be to say that the PyPI maintainers may pre-emptively
declare particular project names invalid for security reasons.
That would not only cover pkg_resources specifically, but also things
like the name normalisation scheme that prevents the use of names that
are deemed "the same as" (as defined by the regex in PEP 508), or
"confusable with" (as defined by the Unicode Consortium), existing
>> * project is name squatting (package has no functionality or is
>> * project name, description, or content violates the Code of Conduct;
>> * project is abusing the Package Index for purposes it was not
>> If you find a project that might be considered invalid, create
>> a support request _.
> It would also be good to add some wording which makes it clear
> that the PSF Board has the final say in any disputes and can
> have a project removed/reassigned after careful consideration
> even when not meeting all the requirements listed in the PEP.
> As an example, the last two bullets you mention above will
> often be subject to additional judgement. The board would then have
> to decide these on a case-by-case basis.
Right, explicitly mentioning the role of the PSF in the process was
going to be my suggestion as well.
I think there are a few key aspects of that which should be mentioned:
- the Python Software Foundation is the legal entity ultimately
responsible for providing the Python Packaging Index as a community
- the PyPI maintainers can always escalate name retention and transfer
questions to the PSF Board for discussion and resolution if they're
not clear on an appropriate course of action
- third parties may escalate name retention and transfer concerns to
the PSF Board if they have a sincere belief that an issue's resolution
is contrary to the documented policy
- issues involving legal claims (copyright disputes, trademark
disputes, patent claims, unauthorized disclosure claims) MUST be
escalated to the Board for review by the PSF's General Counsel
And as with any other changes to the PyPI terms of service, changes to
the project name retention and transfer policy must be approved by the
Foundation (whether that's through the General Counsel's sign-off, or
through a Board resolution would be for the Board to determine, it
doesn't need to be part of the policy)
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG