Withdraw PEPs 426 and 459 (#579)
PEP 566 defines a metadata 2.1 specification that matches the way tools are actually currently working, so we're going to run with that "solve problems we know we have", rather than pursuing the more speculative ground-up metadata redesign that PEP 426 became.
This commit is contained in:
Nick Coghlan
GitHub
parent
d8411b76d7
commit
0977d33b02
58
pep-0426.txt
58
pep-0426.txt
|
|
@ -7,7 +7,7 @@ Author: Nick Coghlan <ncoghlan@gmail.com>,
|
|||
Donald Stufft <donald@stufft.io>
|
||||
BDFL-Delegate: Donald Stufft <donald@stufft.io>
|
||||
Discussions-To: Distutils SIG <distutils-sig@python.org>
|
||||
Status: Deferred
|
||||
Status: Withdrawn
|
||||
Type: Informational
|
||||
Content-Type: text/x-rst
|
||||
Requires: 440, 508, 518
|
||||
|
|
@ -18,6 +18,20 @@ Post-History: 14 Nov 2012, 5 Feb 2013, 7 Feb 2013, 9 Feb 2013,
|
|||
Replaces: 345
|
||||
|
||||
|
||||
PEP Withdrawal
|
||||
==============
|
||||
|
||||
The ground-up metadata redesign proposed in this PEP has been withdrawn in
|
||||
favour of the more modest proposal in PEP 566, which retains the basic
|
||||
Key:Value format of previous metadata versions, but also defines a standardised
|
||||
mechanism for translating that format to nested JSON-compatible data structures.
|
||||
|
||||
Some of the ideas in this PEP (or the related PEP 459) may still be considered
|
||||
as part of later proposals, but they will be handled in a more incremental
|
||||
fashion, rather than as a single large proposed change with no feasible
|
||||
migration plan.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
|
|
@ -25,16 +39,13 @@ This PEP describes a mechanism for publishing and exchanging metadata
|
|||
related to Python distributions. It includes specifics of the field names,
|
||||
and their semantics and usage.
|
||||
|
||||
This document specifies version 3.0 of the metadata format.
|
||||
This document specifies the never released version 2.0 of the metadata format.
|
||||
|
||||
Version 1.0 is specified in PEP 241.
|
||||
Version 1.1 is specified in PEP 314.
|
||||
Version 1.2 is specified in PEP 345.
|
||||
|
||||
Version 2.0 is specified in earlier drafts of this PEP and was never formally
|
||||
approved for use.
|
||||
|
||||
Version 3.0 of the metadata format migrates from directly defining a
|
||||
Version 2.0 of the metadata format proposed migrating from directly defining a
|
||||
custom key-value file format to instead defining a JSON-compatible in-memory
|
||||
representation that may be used to define metadata representation in other
|
||||
contexts (such as API and archive format definitions).
|
||||
|
|
@ -44,8 +55,8 @@ fields to be added for particular purposes without requiring updates to
|
|||
the core metadata format.
|
||||
|
||||
|
||||
Note on PEP Deferral
|
||||
====================
|
||||
Note on PEP History
|
||||
===================
|
||||
|
||||
This PEP was initially deferred for an extended period, from December 2013
|
||||
through to March 2017, as distutils-sig worked through a number of other
|
||||
|
|
@ -74,7 +85,7 @@ of publishing and distributing software to be moved out to PEP 459, a separate
|
|||
proposal for a number of standard metadata extensions that provide additional
|
||||
optional information about a release.
|
||||
|
||||
As of September 2017, it has been deferred again, on the grounds that
|
||||
As of September 2017, it was deferred again, on the grounds that
|
||||
it doesn't actually help solve any particularly pressing problems:
|
||||
|
||||
- JSON representation would be better handled through defining a
|
||||
|
|
@ -87,6 +98,9 @@ it doesn't actually help solve any particularly pressing problems:
|
|||
.. _specifications: https://packaging.python.org/specifications/
|
||||
.. _minor spec version update: https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html
|
||||
|
||||
Finally, the PEP was withdrawn in February 2018 in favour of PEP 566 (which
|
||||
pursues that more incremental strategy).
|
||||
|
||||
|
||||
Purpose
|
||||
=======
|
||||
|
|
@ -391,7 +405,7 @@ binary archive from a source archive.
|
|||
These locations are to be confirmed, since they depend on the definition
|
||||
of sdist 2.0 and the revised installation database standard. There will
|
||||
also be a wheel 1.1 format update after this PEP is approved that
|
||||
mandates provision of 3.0+ metadata.
|
||||
mandates provision of 2.0+ metadata.
|
||||
|
||||
Note that these metadata files MAY be processed even if the version of the
|
||||
containing location is too low to indicate that they are valid. Specifically,
|
||||
|
|
@ -414,7 +428,7 @@ used directly as a data input format. Generating the metadata as part of the
|
|||
publication process also helps to deal with version specific fields (including
|
||||
the source URL and the version field itself).
|
||||
|
||||
For backwards compatibility with older installation tools, metadata 3.0
|
||||
For backwards compatibility with older installation tools, metadata 2.0
|
||||
files MAY be distributed alongside legacy metadata.
|
||||
|
||||
Index servers MAY allow distributions to be uploaded and installation tools
|
||||
|
|
@ -443,8 +457,8 @@ with RFC 3986.
|
|||
The current version of the schema file covers the previous draft of the
|
||||
PEP, and has not yet been updated for the split into the essential
|
||||
dependency resolution metadata and multiple standard extensions, and nor
|
||||
has it been updated for the various other differences between the 3.0
|
||||
draft and the earlier 2.0 drafts.
|
||||
has it been updated for the various other differences between the current
|
||||
draft and the earlier drafts.
|
||||
|
||||
|
||||
Core metadata
|
||||
|
|
@ -467,7 +481,7 @@ installation to occur.
|
|||
Metadata version
|
||||
----------------
|
||||
|
||||
Version of the file format; ``"3.0"`` is the only legal value.
|
||||
Version of the file format; ``"2.0"`` is the only legal value.
|
||||
|
||||
Automated tools consuming metadata SHOULD warn if ``metadata_version`` is
|
||||
greater than the highest version they support, and MUST fail if
|
||||
|
|
@ -481,7 +495,7 @@ all of the needed fields.
|
|||
|
||||
Example::
|
||||
|
||||
"metadata_version": "3.0"
|
||||
"metadata_version": "2.0"
|
||||
|
||||
|
||||
Generator
|
||||
|
|
@ -1046,7 +1060,7 @@ Appendix A: Conversion notes for legacy metadata
|
|||
================================================
|
||||
|
||||
The reference implementations for converting from legacy metadata to
|
||||
metadata 3.0 are:
|
||||
metadata 2.0 are:
|
||||
|
||||
* the `wheel project <https://bitbucket.org/dholth/wheel/overview>`__, which
|
||||
adds the ``bdist_wheel`` command to ``setuptools``
|
||||
|
|
@ -1114,7 +1128,7 @@ format.
|
|||
Appendix C: Summary of differences from \PEP 345
|
||||
=================================================
|
||||
|
||||
* Metadata-Version is now 3.0, with semantics specified for handling
|
||||
* Metadata-Version is now 2.0, with semantics specified for handling
|
||||
version changes
|
||||
|
||||
* The increasingly complex ad hoc "Key: Value" format has been replaced by
|
||||
|
|
@ -1175,7 +1189,7 @@ provision of multiple versions of the metadata in parallel.
|
|||
|
||||
Existing tools won't abide by this guideline until they're updated to
|
||||
support the new metadata standard, so the new semantics will first take
|
||||
effect for a hypothetical 2.x -> 3.0 transition. For the 1.x -> 3.0
|
||||
effect for a hypothetical 2.x -> 3.0 transition. For the 1.x -> 2.x
|
||||
transition, we will use the approach where tools continue to produce the
|
||||
existing supplementary files (such as ``entry_points.txt``) in addition
|
||||
to any equivalents specified using the new features of the standard
|
||||
|
|
@ -1283,7 +1297,7 @@ packages.
|
|||
|
||||
The ability to declare an extension as required is included primarily to
|
||||
allow the definition of the metadata hooks extension to be deferred until
|
||||
some time after the initial adoption of the metadata 3.0 specification. If
|
||||
some time after the initial adoption of the metadata 2.0 specification. If
|
||||
a release needs a ``postinstall`` hook to run in order to complete
|
||||
the installation successfully, then earlier versions of tools should fall
|
||||
back to installing from source rather than installing from a wheel file and
|
||||
|
|
@ -1299,10 +1313,10 @@ order to better prioritise our efforts in migrating to the new metadata
|
|||
standard. These all reflect information that may be nice to have in the
|
||||
new metadata, but which can be readily added through metadata extensions or
|
||||
in metadata 2.1 without breaking any use cases already supported by metadata
|
||||
3.0.
|
||||
2.0.
|
||||
|
||||
Once the ``pypi``, ``setuptools``, ``pip``, ``wheel`` and ``distlib``
|
||||
projects support creation and consumption of metadata 3.0, then we may
|
||||
projects support creation and consumption of metadata 2.0, then we may
|
||||
revisit the creation of metadata 2.1 with some or all of these additional
|
||||
features.
|
||||
|
||||
|
|
@ -1484,7 +1498,7 @@ the idea won't be reconsidered until metadata 2.1 at the earliest).
|
|||
References
|
||||
==========
|
||||
|
||||
This document specifies version 3.0 of the metadata format.
|
||||
This document specifies version 2.0 of the metadata format.
|
||||
Version 1.0 is specified in PEP 241.
|
||||
Version 1.1 is specified in PEP 314.
|
||||
Version 1.2 is specified in PEP 345.
|
||||
|
|
|
|||
29
pep-0459.txt
29
pep-0459.txt
|
|
@ -5,7 +5,7 @@ Last-Modified: $Date$
|
|||
Author: Nick Coghlan <ncoghlan@gmail.com>
|
||||
BDFL-Delegate: Nick Coghlan <ncoghlan@gmail.com>
|
||||
Discussions-To: Distutils SIG <distutils-sig@python.org>
|
||||
Status: Deferred
|
||||
Status: Withdrawn
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Requires: 426
|
||||
|
|
@ -13,6 +13,17 @@ Created: 11 Nov 2013
|
|||
Post-History: 21 Dec 2013
|
||||
|
||||
|
||||
PEP Withdrawal
|
||||
==============
|
||||
|
||||
This PEP depends on PEP 426, which has itself been withdrawn. See the
|
||||
PEP Withdrawal section in that PEP for details.
|
||||
|
||||
In the meantime, metadata extensions will continue to be handled as they
|
||||
have been for past examples like ``entry_points.txt``: as additional files
|
||||
installed into metadata directories alongside the main `METADATA` file.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
|
|
@ -22,22 +33,6 @@ Like all metadata extensions, each standard extension format is
|
|||
independently versioned. Changing any of the formats requires an update
|
||||
to this PEP, but does not require an update to the core packaging metadata.
|
||||
|
||||
PEP Deferral
|
||||
============
|
||||
|
||||
This PEP depends on PEP 426, which has itself been deferred. See the
|
||||
PEP Deferral section in that PEP for details.
|
||||
|
||||
.. note::
|
||||
|
||||
These extensions may eventually be separated out into their own PEPs,
|
||||
but we're already suffering from PEP overload in the packaging
|
||||
metadata space.
|
||||
|
||||
This PEP was initially created by slicing out large sections of earlier
|
||||
drafts of PEP 426 and making them extensions, so some of the specifics
|
||||
may still be rough in the new context.
|
||||
|
||||
|
||||
Standard Extension Namespace
|
||||
============================
|
||||
|
|
|
|||
Loading…
Reference in New Issue