Updates pep527 (#74)

* PEP 527 BDFL Delegate is Nick Coghlan
* Allow both .zip and .tar.gz and expand upon rationale
This commit is contained in:
Donald Stufft 2016-08-24 16:45:14 -04:00 committed by GitHub
parent f87f1209e0
commit 085703bc03
1 changed files with 40 additions and 37 deletions

View File

@ -3,7 +3,7 @@ Title: Removing Un(der)used file types/extensions on PyPI
Version: $Revision$
Last-Modified: $Date$
Author: Donald Stufft <donald@stufft.io>
BDFL-Delegate: TBD <donald@stufft.io>
BDFL-Delegate: Nick Coghlan <ncoghlan@gmail.com>
Discussions-To: distutils-sig@python.org
Status: Draft
Type: Process
@ -23,9 +23,8 @@ it recommends disallowing further uploads of any files of the types
``bdist_wheel``, and ``bdist_egg`` file types.
In addition, this PEP proposes removing support for new uploads of sdists using
the ``.tar``, ``.tar.bz2``, ``.tar.xz``, ``.zip``, ``.tar.Z``, ``.tgz``,
``.tbz``, and any other extension besides ``.tar.gz``.
the ``.tar``, ``.tar.bz2``, ``.tar.xz``, ``.tar.Z``, ``.tgz``, ``.tbz``, and
any other extension besides ``.tar.gz`` and ``.zip``.
Rationale
@ -50,6 +49,37 @@ general use in the ecosystem. Continuing to support them adds a maintenance
burden on PyPI as well as tool authors and incurs a cost in both bandwidth and
disk space not only on PyPI itself, but also on any mirrors of PyPI.
Python packaging is a multi-level ecosystem where PyPI is primarily suited and
used to distribute virtual environment compatible packages directly from their
respective project owners. These packages are then consumed either directly
by end-users, or by downstream distributors that take these packages and turn
them into their respective system level packages (such as RPM, deb, MSI, etc).
While PyPI itself only directly works with these Python specific but platform
agnostic packages, we encourage community-driven and commercial conversions of
these packages to downstream formats for particular target environments, like:
* The conda cross-platform data analysis ecosystem (conda-forge)
* The deb based Linux ecosystem (Debian, Ubuntu, etc)
* The RPM based Linux ecosystem (Fedora, openSuSE, Mageia, etc)
* The homebrew, MacPorts and fink ecosystems for Mac OS X
* The Windows Package Management ecosystem (NuGet, Chocalatey, etc)
* 3rd party creation of Windows MSIs and installers (e.g. Christoph Gohlke's
work at http://www.lfd.uci.edu/~gohlke/pythonlibs/ )
* other commercial redistribution formats (ActiveState's PyPM, Enthought
Canopy, etc)
* other open source community redistribution formats (Nix, Gentoo, Arch, \*BSD,
etc)
It is the belief of this PEP that the entire ecosystem is best supported by
keeping PyPI focused on the platform agnostic formats, where the limited amount
of time by volunteers can be best used instead of spreading the available time
out amongst several platforms. Further more, this PEP believes that the people
best positioned to provide well integrated packages for a particular platform
are people focused on that platform, and not across all possible platforms.
bdist_dumb
~~~~~~~~~~
@ -160,33 +190,8 @@ both use the same C library (``zlib``) which is also required for
is the default, on Windows ``.zip`` is the default and the ``bdist_wheel``
format also uses zip.
This PEP proposes that we drop the use of ``.zip`` extensions for sdists on
PyPI and standardize around ``.tar.gz``. For both extensions there are going to
be automation designed by end users which are making assumptions about what the
file extension produced by the ``sdist`` command will be. Changing either
default will break some number of those, so by changing the default of ``.zip``
to ``.tar.gz`` we minimize the amount of breakage by taking the smaller number
of users and making them match the larger number. In addition, it's more likely
to see Windows users upgrade their setuptools and Python releases on a faster
timescale than POSIX users. POSIX users often get their Python and setuptools
from their OS vendor and are discouraged or actively prevented from upgrading
them outside of complete OS upgrades while Windows users *must* install Python
and setuptools on their own, and thus are more able to upgrade those pieces
without triggering a complete OS upgrade.
While it is true that switching to ``.zip`` would align ``sdist`` with
``bdist_wheel`` in terms of format, this is not a very large benefit because
both formats are able to be manipulated with the Python standard library just
as easily and both require the same C library (``zlib``). It is also true that
Windows has support for ``.zip`` files out of the box but requires third party
software for ``.tar.gz``, however only 0.6% of downloads for sdists on PyPI are
initiated by browsers and we can assume that only a fraction of those 0.6% are
Windows users who want to manually extract the file and do not have a means of
extracting a ``.tar.gz``, particularly since Python itself can be used to
extract a ``.tar.gz`` via the command line since version 3.4. In addition, the
use of ``.tar.gz`` will result in smaller sdists which will reduce the amount
of bandwidth and disk space consumed by ``sdist`` files.
Instead of trying to standardize on either ``.tar.gz`` or ``.zip``, this PEP
proposes that we allow *either* ``.tar.gz`` or ``.zip`` for sdists.
Removal Process
===============
@ -198,18 +203,16 @@ applicable.
First, any *existing* projects will be flagged to allow legacy file types to be
uploaded, and any project without that flag (i.e. new projects) will not be
able to upload anything but ``sdist`` with a ``.tar.gz`` extension,
able to upload anything but ``sdist`` with a ``.tar.gz`` or ``.zip`` extension,
``bdist_wheel``, and ``bdist_egg``. Then, any existing projects that have never
uploaded a file that requires the legacy file type flag will have that flag
removed, also making them fall under the new restrictions. Finally, an email
will be generated to the maintainers of all projects still given the legacy
flag, which will inform them of the upcoming new restrictions on uploads and
tell them that these restrictions will be applied to future uploads to their
projects starting in 1 month. This email should also contain work arounds for
older versions of Python/setuptools on Windows, to get a ``.tar.gz`` by
default. Finally, after 1 month all projects will have the legacy file type
flag removed, and support for uploading these types of files will cease to
exist on PyPI.
projects starting in 1 month. Finally, after 1 month all projects will have the
legacy file type flag removed, and support for uploading these types of files
will cease to exist on PyPI.
This plan should provide minimal disruption since it does not remove any
existing files, and the types of files it does prevent from being uploaded are