Officially defer PEP 426 (Metadata 2.0)

pep-0426.txt

@@ -7,7 +7,7 @@ Author: Nick Coghlan <ncoghlan@gmail.com>,
         Donald Stufft <donald@stufft.io>
 BDFL-Delegate: Nick Coghlan <ncoghlan@gmail.com>
 Discussions-To: Distutils SIG <distutils-sig@python.org>
-Status: Draft
+Status: Deferred
 Type: Standards Track
 Content-Type: text/x-rst
 Requires: 440
@@ -39,13 +39,37 @@ support for optional dependencies. Finally, this version addresses
 several issues with the previous iteration of the standard version
 identification scheme.
 
+PEP Deferral
+============
+
+Migrating to a new metadata format is current deferred indefinitely, with
+distutils-sig instead focusing on a more incremental approach to allowing
+parts of the ecosystem to be independently upgraded without breaking the world.
+
+Some of those incremental improvements include:
+
+* PEP 425, defining a compatibility tagging mechanism for binary files
+* PEP 427, defining the pre-built "wheel" format
+* PEP 440, covering the versioning identification and selection scheme
+* PEP 503, ``/simple/`` package repository API
+* PEP 508, covering dependency declarations and environment markers
+* PEP 513, defining the "manylinux1" compatibility tag
+* PEP 518, defining a static config file for sdist build system dependencies
+
+Other planned improvements in various stages of development include:
+
+* Supporting build systems that don't provide the `setup.py` command
+* Supporting additional semantic categories for distribution contents (based on
+  GNU autotools)
+* Support for declaring dependencies on shared system libraries
+
 .. note::
 
    "I" in this doc refers to Nick Coghlan. Daniel and Donald either wrote or
-   contributed to earlier versions, and have been providing feedback as this
+   contributed to earlier versions, and provided feedback as the JSON-based
-   JSON-based rewrite has taken shape. Daniel and Donald have also been
+   rewrite took shape. Daniel and Donald were also vetting the proposal as we
-   vetting the proposal as we go to ensure it is practical to implement for
+   went to ensure it remained practical to implement for both clients and
-   both clients and index servers.
+   index servers.
 
    Metadata 2.0 represents a major upgrade to the Python packaging ecosystem,
    and attempts to incorporate experience gained over the 15 years(!) since
@@ -58,21 +82,6 @@ identification scheme.
    source packages for at least Debian and Fedora, and perhaps other
    platform specific distribution systems).
 
-   There will eventually be a suite of PEPs covering various aspects of
-   the metadata 2.0 format and related systems:
-
-   * this PEP, covering the core metadata format
-   * PEP 440, covering the versioning identification and selection scheme
-   * PEP 459, covering several standard extensions
-   * PEP 496, covering environment markers
-   * a yet-to-be-written PEP to define v2.0 of the sdist format
-   * an updated wheel PEP (v1.1) to add pydist.json (and possibly convert
-     the wheel metadata file from Key:Value to JSON)
-   * an updated installation database PEP to add pydist.json
-   * a PEP to standardise the expected command line interface for setup.py
-     as an interface to an application's build system (rather than requiring
-     that the build system support the distutils command system)
-
    It's going to take a while to work through all of these and make them
    a reality. The main change from our last attempt at this is that we're
    trying to design the different pieces so we can implement them