[Python-checkins] peps: Add Paul Moore as Delegate, remove Data Sovereignty section, add Opposition

[donald.stufft]

https://hg.python.org/peps/rev/8cc94276db23
changeset:   6007:8cc94276db23
parent:      5996:6c8a8f29a798
user:        Donald Stufft <donald at stufft.io>
date:        Sat Aug 29 10:40:20 2015 -0400
summary:
  Add Paul Moore as Delegate, remove Data Sovereignty section, add Opposition section

files:
  pep-0470.txt |  49 +++++++++++++++++++++++----------------
  1 files changed, 29 insertions(+), 20 deletions(-)


diff --git a/pep-0470.txt b/pep-0470.txt
--- a/pep-0470.txt
+++ b/pep-0470.txt
@@ -2,8 +2,8 @@
 Title: Removing External Hosting Support on PyPI
 Version: $Revision$
 Last-Modified: $Date$
-Author: Donald Stufft <donald at stufft.io>,
-BDFL-Delegate: TBD
+Author: Donald Stufft <donald at stufft.io>
+BDFL-Delegate: Paul Moore <p.f.moore at gmail.com>
 Discussions-To: distutils-sig at python.org
 Status: Draft
 Type: Process
@@ -284,26 +284,35 @@
 Remote Code Execution via a Man In The Middle attack.
 
 
-Data Sovereignty
-================
+Opposition
+==========
 
-In the discussions around previous versions of this PEP, one of the key use
-cases for wanting to host files externally to PyPI was due to data sovereignty
-requirements for people living in jurisdictions outside of the USA, where PyPI
-is currently hosted. The author of this PEP is not blind to these concerns and
-realizes that this PEP represents a regression for the people that have these
-concerns, however the current situation is presenting an extremely poor user
-experience and the feature is only being used by a small percentage of
-projects. In addition, the data sovereignty problems requires familarity with
-the laws outside of the home jurisdiction of the author of this PEP, who is
-also the principal developer and operator of PyPI. For these reasons, a
-solution for the problem of data sovereignty has been deferred and is
-considered outside of the scope for this PEP.
+The primary opposition to this PEP is that some people may want to not host on
+PyPI for any number of reasons such as the PyPI Terms of Service or Data
+Sovereignty requirements for a particular jurisdiction. For these people this
+PEP represents a regression in the ability for end users to discover what
+options are required to install their projects.
 
-The data sovereignty issue will need to  be addressed by someone with an
-understanding of the restrictions and constraints involved. As the author of
-this PEP does not have that expertise, it should be addressed in a separate
-PEP.
+The projects that are currently unwilling to host on PyPI can be split into
+two general categories, those that would be willing to host on PyPI but for
+some particular missing feature, and those that will never be willing to host
+on PyPI for any reason.
+
+It is the opinion of this PEP that for those who will never be willing to host
+on PyPI for any reason, that those projects should rely on the support of
+multiple repositories that pip and setuptools already possess and which this
+PEP recommends to all installers. These projects may still use PyPI as an index
+for users to discover through the web interface and should document what
+options are needed in order to install within the long description of their
+projects, which is a freeform field which can structure the information however
+is most useful for their particular project. This is a model which is battle
+tested in virtually every Linux distribution.
+
+For the projects that would host on PyPI but for some particular missing
+feature, it is the opinion of this PEP that instead of the legacy feature that
+this PEP aims to remove, they would be be best served by identifying which
+features are missing and then designing a good solution for those particular
+issues.
 
 
 Rejected Proposals

-- 
Repository URL: https://hg.python.org/peps