iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add Paul Moore as Delegate, remove Data Sovereignty section, add Opposition section

This commit is contained in:
Donald Stufft 2015-08-29 10:40:20 -04:00
parent 61eadfb105
commit e3731d161a
1 changed files with 29 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
pep-0470.txt
View File

@ -2,8 +2,8 @@ PEP: 470
Title: Removing External Hosting Support on PyPI
Version: $Revision$
Last-Modified: $Date$
Author: Donald Stufft <donald@stufft.io>,
BDFL-Delegate: TBD
Author: Donald Stufft <donald@stufft.io>
BDFL-Delegate: Paul Moore <p.f.moore@gmail.com>
Discussions-To: distutils-sig@python.org
Status: Draft
Type: Process
@ -284,26 +284,35 @@ safely host outside of PyPI while 95% of them are exposing their users to
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