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:
parent
f87f1209e0
commit
085703bc03
77
pep-0527.txt
77
pep-0527.txt
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue