pep-0432.txt

pep-0426.txt

@@ -86,6 +86,24 @@ identification scheme.
    "rationale" section at the end of the document, as it would otherwise be
    an irrelevant distraction for future readers.
 
+
+A Note on Time Frames
+=====================
+
+There's a lot of work going on in the Python packaging space at the moment.
+In the near term (up until the release of Python 3.4), those efforts will be
+focused on the existing metadata standards, both those defined in Python
+Enhancement Proposals, and the de facto standards defined by the setuptools
+project.
+
+This PEP is about setting out a longer term goal for the ecosystem that
+captures those existing capabilities in a format that is easier to work
+with. There are still a number of key open questions (mostly related to
+source based distribution), and those won't be able to receive proper
+attention from the development community until the other near term
+concerns have been resolved.
+
+
 Purpose
 =======
 
@@ -223,12 +241,16 @@ or consumes distribution version and dependency metadata.
 along with the supporting metadata file formats defined by the
 ``setuptools`` project.
 
-"Entry points" are a scheme for identifying Python callables or other
-objects as strings consisting of a Python module name and a module
-attribute name, separated by a colon. For example: ``"test.regrtest:main"``.
+"Distro" is used as the preferred term for Linux distributions, to help
+avoid confusion with the Python-specific meaning of the term "distribution".
 
-"Distros" is used as the preferred term for Linux distributions, to help
-avoid confusion with the Python-specific meaning of the term.
+"Dist" is the preferred abbreviation for "distributions" in the sense defined
+in this PEP.
+
+"Qualified name" comes from PEP 3155, and refers to the name of an
+object relative to its containing module. This is useful for referring
+to method definitions on classes, as well as any other attributes of
+top level module objects.
 
 
 Integration and deployment of distributions
@@ -255,7 +277,10 @@ Integration and deployment can in turn be broken down into further substeps.
 These three steps may all occur directly on the target system. Alternatively
 the build step may be separated out by using binary archives provided by the
 publisher of the distribution, or by creating the binary archives on a
-separate system prior to deployment.
+separate system prior to deployment. The advantage of the latter approach
+is that it minimizes the dependencies that need to be installed on
+deployment targets (as the build dependencies will be needed only on the
+build systems).
 
 The published metadata for distributions SHOULD allow integrators, with the
 aid of build and integration tools, to:
@@ -299,6 +324,25 @@ and publishers, with the aid of build and publication tools, to:
 Standard build system
 ---------------------
 
+.. note::
+
+   The standard build system currently described in the PEP is a draft based
+   on existing practices for projects using distutils or setuptools as their
+   build system (or other projects, like ``d2to1``, that expose a setup.py
+   file for backwards compatibility with existing tools)
+
+   The specification doesn't currently cover expected argument support for
+   the commands, which is a limitation that needs to be addressed before the
+   PEP can be considered ready for acceptance.
+
+   It is also possible that the "meta build system" will be separated out
+   into a distinct PEP in the coming months (similar to the separation of
+   the versioning and requirement specification standard out to PEP 440).
+
+   If a `suitable API can be worked out <Metabuild system>`__, then it may
+   even be possible to switch to a more declarative API for build system
+   specification.
+
 Both development and integration of distributions relies on the ability to
 build extension modules and perform other operations in a distribution
 independent manner.
@@ -318,10 +362,6 @@ development and integration activities:
 * ``python setup.py bdist_wheel``: create a binary archive from an sdist,
   source archive or VCS checkout
 
-Future iterations of the metadata and associated PEPs may aim to replace
-these ``distutils``/``setuptools`` dependent commands with build system
-independent entry points.
-
 
 Metadata format
 ===============
@@ -436,6 +476,48 @@ When serialised to a file, the name used for this metadata set SHOULD
 be ``pydist-dependencies.json``.
 
 
+Export metadata
+---------------
+
+Distributions may define components that are intended for use by other
+distributions (such as plugins). As it can be beneficial to know whether or
+not a distribution defines any such exports without needing to parse any
+metadata, a suitable subset is defined for serialisation to a separate file
+in the ``dist-info`` metadata directory.
+
+The external command metadata consists of the following fields:
+
+* ``metadata_version``
+* ``generator``
+* ``name``
+* ``version``
+* ``exports``
+
+When serialised to a file, the name used for this metadata set SHOULD
+be ``pydist-exports.json``.
+
+
+External command metadata
+-------------------------
+
+Distributions may define commands that will be available from the command
+line following installation. As it can be beneficial to know whether or not
+a distribution has external commands without needing to parse any metadata,
+a suitable subset is defined for serialisation to a separate file in the
+``dist-info`` metadata directory.
+
+The external command metadata consists of the following fields:
+
+* ``metadata_version``
+* ``generator``
+* ``name``
+* ``version``
+* ``commands``
+
+When serialised to a file, the name used for this metadata set SHOULD
+be ``pydist-commands.json``.
+
+
 Included documents
 ------------------
 
@@ -1482,6 +1564,33 @@ extension when creating an sdist, and use those when creating the wheel
 files later.
 
 
+Exported interfaces
+===================
+
+Most Python distributions expose packages and modules for import through
+the Python module namespace.
+
+Extensions to the metadata may be present in a mapping under the
+'extensions' key.  The keys must meet the same restrictions as
+distribution names, while the values may be any type natively supported
+in JSON::
+
+    "extensions" : {
+      "chili" : { "type" : "Poblano", "heat" : "Mild" },
+      "languages" : [ "French", "Italian", "Hebrew" ]
+    }
+
+To avoid name conflicts, it is RECOMMENDED that distribution names be used
+to identify metadata extensions. This practice will also make it easier to
+find authoritative documentation for metadata extensions.
+
+Metadata extensions allow development tools to record information in the
+metadata that may be useful during later phases of distribution. For
+example, a build tool could include default build options in a metadata
+extension when creating an sdist, and use those when creating the wheel
+files later.
+
+
 Extras (optional dependencies)
 ==============================
 

pep-0432.txt

@@ -3,11 +3,11 @@ Title: Simplifying the CPython startup sequence
 Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Coghlan <ncoghlan@gmail.com>
-Status: Draft
+Status: Deferred
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 28-Dec-2012
-Python-Version: 3.4
+Python-Version: 3.5
 Post-History: 28-Dec-2012, 2-Jan-2013
 
 
@@ -25,6 +25,31 @@ resolution for most of these should become clearer as the reference
 implementation is developed.
 
 
+PEP Deferral
+============
+
+Python 3.4 is nearing its first alpha, and already includes a couple of
+significant low level changes in PEP 445 (memory allocator customisation)
+and PEP 442 (safe object finalization). As a result of the latter PEP,
+the shutdown procedure of CPython has also been changed to be more heavily
+reliant on the cyclic garbage collector, significantly reducing the
+number of modules that will experience the "module globals set to None"
+behaviour that is used to deliberate break cycles and attempt to releases
+more external resources cleanly.
+
+Furthermore, I am heavily involved in the current round of updates to the
+Python packaging ecosystem (as both the lead author of PEP 426 and
+BDFL-delegate for several other PEPs), leaving little to spare to work on
+this proposal. The other developers I would trust to lead this effort are
+also working on other things.
+
+So, due to those practical resource constraints, the proximity of Python
+3.4 deadlines, and recognition that making too many significant changes to
+the low level CPython infrastructure in one release is likely to be unwise,
+further work on this PEP has been deferred to the Python 3.5 development
+cycle.
+
+
 Proposal
 ========