[Distutils] RFC: PEP 541 - Package Index Name Retention
Anna Ravenscroft
annaraven at gmail.com
Fri Jan 13 13:27:39 EST 2017
+1 on the proposal.
I would suggest to state where it is posted (somewhere obvious) on pypi,
and possibly some kind of automated notification to pypi uploaders be
provided about the new policy.
On Fri, Jan 13, 2017 at 10:08 AM, Lukasz Langa <lukasz at langa.pl> wrote:
> Hello distutils-sig,
> I'd like to get some comments on this. I was asked by Donald to work on
> it. It removes ambiguity from some of the situations that crop up
> increasingly often with regards to package names on the PyPI. Looking
> forward to hearing what you have to say!
> - Ł
>
>
> PEP: 541
> Title: Package Index Name Retention
> Version: $Revision$
> Last-Modified: $Date$
> Author: Łukasz Langa <lukasz at langa.pl>
> Status: Draft
> Type: Process
> Content-Type: text/x-rst
> Created: 12-January-2017
>
>
> Abstract
> ========
>
> This PEP proposes an extension to the Terms of Use [1]_ of the Package
> Index [2]_, clarifying expectations of package owners regarding
> ownership of a package name on the Package Index, specifically with
> regards to conflict resolution.
>
> Existing package repositories such as CPAN [3]_, NPM [4]_, and
> GitHub [5]_ will be investigated as prior art in this field.
>
>
> Rationale
> =========
>
> Given that package names on the Index are sharing a single flat
> namespace, a unique name is a finite resource. The growing age of
> the Package Index causes a constant rise of situations of conflict
> between the current use of the name and a different suggested use of
> the same name.
>
> This document aims to provide general guidelines for solving the
> most typical cases of such conflicts.
>
>
> Specification
> =============
>
> The main idea behind this document is that the Package Index serves the
> community. Every user is invited to upload content to the Package Index
> under the Terms of Use, understanding that it is at the sole risk of
> the user.
>
> While the Package Index is not a backup service, the maintainers of the
> Package Index do their best to keep that content accessible indefinitely
> in its published form. However, in certain edge cases the greater
> community's needs might overweigh the individual's expectation of
> ownership of a package name.
>
> The use cases covered by this document are:
>
> * Abandoned projects:
>
> * continued maintenance by a different set of users; or
> * removal from the Index for use with a different project.
>
> * Active projects:
>
> * resolving disputes over a name.
>
> * Invalid projects.
>
>
> Implementation
> ==============
>
> Reachability
> ------------
>
> The user of the Package Index is solely responsible for being reachable
> by the Package Index maintainers for matters concerning projects that
> the user owns. In every case where contacting the user is necessary,
> the maintainers will try to do so at least three times, using the
> following means of contact:
>
> * the e-mail address on file in the user's profile on the Package Index;
> * the e-mail address listed in the Author field for a given project
> uploaded to the Index; and
> * any e-mail addresses found in the given project's documentation
> on the Index or on the listed Home Page.
>
> The maintainers stop trying to reach the user after six weeks.
>
>
> Abandoned projects
> ------------------
>
> A project is considered *abandoned* when ALL of the following are met:
>
> * owner not reachable (see Reachability above);
> * no releases within the past twelve months; and
> * no activity from the owner on the project's home page (or no
> home page listed).
>
> All other projects are considered *active*.
>
>
> Continued maintenance of an abandoned project
> ---------------------------------------------
>
> If a candidate appears willing to continue maintenance on an *abandoned*
> project, ownership of the name is transferred when ALL of the following
> are met:
>
> * the project has been determined *abandoned* by the rules described
> above;
> * the candidate is able to demonstrate own failed attempts to contact
> the existing owner;
> * the candidate is able to demonstrate skin in the game (improvements
> made on the candidate's own fork of the project);
> * the candidate is able to demonstrate why a fork under a different name
> is not an acceptable workaround; and
> * the maintainers of the Package Index don't have any additional
> reservations.
>
> Under no circumstances will a name be reassigned against the wishes of
> a reachable owner.
>
>
> Removal of an abandoned project
> -------------------------------
>
> Projects are never removed from the Package Index solely on the basis
> of abandonment. Artifacts uploaded to the Package Index hold inherent
> historical value.
>
> An *abandoned* project can be transferred to a new owner for purposes
> of reusing the name when ALL of the following are met:
>
> * the project has been determined *abandoned* by the rules described
> above;
> * the candidate is able to demonstrate own failed attempts to contact
> the existing owner;
> * the candidate is able to demonstrate skin in the game (the other
> project suggested to reuse the name already exists and meets
> notability requirements);
> * the candidate is able to demonstrate why a fork under a different name
> is not an acceptable workaround;
> * download statistics on the Package Index for the existing package
> indicate project is not being used; and
> * the maintainers of the Package Index don't have any additional
> reservations.
>
>
> Name conflict resolution for active projects
> --------------------------------------------
>
> The maintainers of the Package Index are not arbiters in disputes
> around *active* projects. There are many possible scenarios here,
> a non-exclusive list describing some real-world examples is presented
> below. None of the following qualify for package name ownership
> transfer:
>
> 1. User A and User B share project X. After some time they part ways
> and each of them wants to continue the project under name X.
> 2. User A owns a project X outside the Package Index. User B creates
> a package under the name X on the Index. After some time, User A
> wants to publish project X on the Index but realizes name is taken.
> This is true even if User A's project X gains notability and the
> User B's project X is not notable.
> 3. User A publishes project X to the Package Index. After some time
> User B proposes bug fixes to the project but no new release is
> published by User A. This is true even if User A agrees to publish
> a new version and later doesn't, even if User B's changes are merged
> to the source code repository for project X.
>
> Again, the list above is not exclusive. The maintainers of the Package
> Index recommend users to get in touch with each other and solve the
> issue by respectful communication (see the PSF Code of Conduct [6]_).
>
>
> Invalid projects
> ----------------
>
> A project published on the Package Index meeting ANY of the following
> is considered invalid and will be removed from the Index:
>
> * project does not conform to Terms of Use;
> * project is malware (designed to exploit or harm systems or users);
> * project contains illegal content;
> * project violates copyright or licenses;
> * project is name squatting (package has no functionality or is
> empty);
> * project name, description, or content violates the Code of Conduct;
> or
> * project is abusing the Package Index for purposes it was not
> intended.
>
> If you find a project that might be considered invalid, create
> a support request [7]_.
>
>
> Prior art
> =========
>
> NPM contains a separate section linked from the front page called
> `Package Name Disputes <https://www.npmjs.com/policies/disputes>`_.
> It is described as a "living document", as of January 2017 its
> contents might be summarized as follows:
>
> * package name squatting is prohibited;
> * users wanting to reuse a project name are required to contact the
> existing author, with cc to support at npmjs.com;
> * all contact must conform to the NPM Code of Conduct;
> * in case of no resolution after a few weeks, npm inc. holds the right
> to the final decision in the matter.
>
> CPAN lets any user upload modules with the same name. PAUSE, a related
> index, only lists modules uploaded by the primary maintainer or listed
> co-maintainers. CPAN documentation doesn't address disputes otherwise.
>
> GitHub's terms of service contain an exhaustive list of behavior
> not meeting general conditions of use. While not codified anywhere,
> GitHub does agree for users to reclaim abandoned account names by
> archiving the abandoned account and letting the other user or
> organization rename their account. This is done on a case-by-case
> basis.
>
>
> Rejected Proposals
> ==================
>
> The original approach was to hope for the best and solve issues as they
> arise without written policy. This is not sustainable. The lack of
> generally available guidelines in writing on package name conflict
> resolution is causing unnecessary tensions. From the perspective of
> users, decisions made by the Package Index maintainers without written
> guidelines may appear arbitrary. From the perspective of the Package
> Index maintainers, solving name conflicts is a stressful task due to
> risk of unintentional harm due to lack of defined policy.
>
>
> References
> ==========
>
> .. [1] Terms of Use of the Python Package Index
> (https://pypi.org/policy/terms-of-use/)
>
> .. [2] The Python Package Index
> (https://pypi.python.org/)
>
> .. [3] The Comprehensive Perl Archive Network
> (http://www.cpan.org/)
>
> .. [4] Node Package Manager
> (https://www.npmjs.com/package/left-pad)
>
> .. [5] GitHub
> (https://github.com/)
>
> .. [6] Python Community Code of Conduct
> (https://www.python.org/psf/codeofconduct/)
>
> .. [7] PyPI Support Requests
> (https://sourceforge.net/p/pypi/support-requests/)
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
>
> Acknowledgements
> ================
>
> The many participants of the Distutils and Catalog SIGs for their
> ideas over the years.
>
> ..
> Local Variables:
> mode: indented-text
> indent-tabs-mode: nil
> sentence-end-double-space: t
> fill-column: 70
> End:
>
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
--
cordially,
Anna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170113/095114a8/attachment-0001.html>
More information about the Distutils-SIG
mailing list