Backed out changeset 54c62ebb0501
This commit is contained in:
Nick Coghlan
parent
8c54950c0e
commit
12b49b6a86
129
pep-0426.txt
129
pep-0426.txt
|
|
@ -86,24 +86,6 @@ 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
|
||||
=======
|
||||
|
||||
|
|
@ -241,16 +223,12 @@ or consumes distribution version and dependency metadata.
|
|||
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".
|
||||
"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"``.
|
||||
|
||||
"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.
|
||||
"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 @@ 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. 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 @@ 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.
|
||||
|
|
@ -362,6 +318,10 @@ 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
|
||||
===============
|
||||
|
|
@ -476,48 +436,6 @@ 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
|
||||
------------------
|
||||
|
||||
|
|
@ -1564,33 +1482,6 @@ 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)
|
||||
==============================
|
||||
|
||||
|
|
|
|||
29
pep-0432.txt
29
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: 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 @@ 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
|
||||
========
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue