[Python-checkins] peps: Backed out changeset 54c62ebb0501
nick.coghlan
python-checkins at python.org
Fri Aug 2 15:09:41 CEST 2013
http://hg.python.org/peps/rev/18dcfa66719a
changeset: 5023:18dcfa66719a
user: Nick Coghlan <ncoghlan at gmail.com>
date: Fri Aug 02 23:08:54 2013 +1000
summary:
Backed out changeset 54c62ebb0501
files:
pep-0426.txt | 131 +++-----------------------------------
pep-0432.txt | 29 +--------
2 files changed, 13 insertions(+), 147 deletions(-)
diff --git a/pep-0426.txt b/pep-0426.txt
--- a/pep-0426.txt
+++ b/pep-0426.txt
@@ -86,24 +86,6 @@
"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
=======
@@ -241,16 +223,12 @@
along with the supporting metadata file formats defined by the
``setuptools`` project.
-"Distro" is used as the preferred term for Linux distributions, to help
-avoid confusion with the Python-specific meaning of the term "distribution".
-
-"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.
+"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"``.
+
+"Distros" is used as the preferred term for Linux distributions, to help
+avoid confusion with the Python-specific meaning of the term.
Integration and deployment of distributions
@@ -277,10 +255,7 @@
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. 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).
+separate system prior to deployment.
The published metadata for distributions SHOULD allow integrators, with the
aid of build and integration tools, to:
@@ -324,25 +299,6 @@
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.
@@ -362,6 +318,10 @@
* ``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
===============
@@ -476,48 +436,6 @@
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
------------------
@@ -1564,33 +1482,6 @@
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)
==============================
diff --git a/pep-0432.txt b/pep-0432.txt
--- a/pep-0432.txt
+++ b/pep-0432.txt
@@ -3,11 +3,11 @@
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <ncoghlan at gmail.com>
-Status: Deferred
+Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Dec-2012
-Python-Version: 3.5
+Python-Version: 3.4
Post-History: 28-Dec-2012, 2-Jan-2013
@@ -25,31 +25,6 @@
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
========
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list