iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 426: tweak standard build system description

This commit is contained in:
Nick Coghlan 2013-06-24 21:38:31 +10:00
parent a157a40e52
commit 00af01985f
1 changed files with 43 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
pep-0426.txt
View File

@ -261,10 +261,8 @@ aid of build and integration tools, to:
* obtain the original source code that was used to create a distribution
* identify and retrieve the dependencies (if any) required to use a
distribution
* identify and retrieve the dependencies (if any) required to build a distribution
from source
* if supported by the distribution, run the distribution's automatic test
suite on an installed instance of the distribution
* identify and retrieve the dependencies (if any) required to build a
distribution from source
* identify and retrieve the dependencies (if any) required to run a
distribution's test suite
* find resources on using and contributing to the project
@ -272,18 +270,6 @@ aid of build and integration tools, to:
publishers through appropriate channels, as well as finding distributions
that are relevant to particular problems
The current iteration of the metadata relies on the ``distutils`` commands
system to support other necessary integration and deployment activities:
* ``python setup.py bdist_wheel``: create a binary archive from a source
archive or checkout
* ``python setup.py test``: run the distribution's test suite on a built
(but not yet installed) distribution
Future iterations of the metadata will aim to replace these ``distutils``/
``setuptools`` dependent commands with build system independent entry
points.
Development and publication of distributions
--------------------------------------------
@ -307,17 +293,30 @@ and publishers, with the aid of build and publication tools, to:
* specify the additional dependencies (if any) required to develop and
publish the distribution
The current iteration of the metadata relies on the ``distutils`` commands
system to support other necessary development and publication activities:
* ``python setup.py dist_info``: generate the ``pymeta.json`` file for a
distribution
Standard build system
---------------------
Both development and integration of distributions relies on the ability to
build extension modules and perform other operations in a distribution
independent manner.
The current iteration of the metadata relies on the
``distutils``/``setuptools`` commands system to support these necessary
development and integration activities:
* ``python setup.py dist_info``: generate distribution metadata in place
given a source archive or VCS checkout
* ``python setup.py sdist``: create an sdist from a source archive
or VCS checkout
* ``python setup.py test``: run the distribution's test suite on a built
(but not yet installed) distribution
* ``python setup.py build_ext --inplace``: build extension modules in place
given an sdist, source archive or VCS checkout
* ``python setup.py test``: run the distribution's test suite in place
given an sdist, source archive or VCS checkout
* ``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 will aim to replace
Future iterations of the metadata and associated PEPs may aim to replace
these ``distutils``/``setuptools`` dependent commands with build system
independent entry points.
@ -1506,11 +1505,12 @@ Installation tools MUST call install hooks solely with keyword arguments.
Install hook implementations MUST use the given parameter names.
Installation tools SHOULD invoke install hooks automatically after
installing a distribution from a binary archive. When installing from
an sdist, source archive or VCS checkout using ``setup.py install``
installation tools MUST NOT invoke the install hooks - it is assumed
that the ``setup.py`` script will already invoke any necessary
post-installation behaviour.
installing a distribution from a binary archive.
When installing from an sdist, source archive or VCS checkout, installation
tools SHOULD create a binary archive using ``setup.py bdist_wheel`` and
then install binary archive normally (including invocation of any install
hooks). Installation tools SHOULD NOT invoke ``setup.py install`` directly.
Installation tools SHOULD treat an exception thrown by a postinstall hook
as a failure of the installation and revert any other changes made to the
@ -2024,8 +2024,9 @@ activities to be pursued independently by the individual platform
communities, while still interoperating with the cross-platform Python
tools.
Falling back to invoking ``setup.py install`` directly remains as the
interim solution for installation from source archives.
Legacy packages that expect to able to run code on target systems using
``setup.py install`` will no longer work correctly. Such packages will
already break when pip 1.4+ is configured to use a wheel cache directory.
Changes to environment markers
@ -2252,8 +2253,9 @@ In the meantime, the above operations will be handled through the
* ``python setup.py dist_info``
* ``python setup.py sdist``
* ``python setup.py bdist_wheel``
* ``python setup.py build_ext --inplace``
* ``python setup.py test``
* ``python setup.py bdist_wheel``
The following metabuild hooks may be defined in metadata 2.1 to
cover these operations without relying on ``setup.py``:
@ -2326,6 +2328,16 @@ using the same import based checks as are used for runtime extras. That
way it doesn't matter if the additional dependencies were requested
explicitly or just happen to be available on the system.
There are still a number of open questions with this design, such as whether
a single build hook is sufficient to cover both "build for testing" and
"prep for deployment", as well as various complexities like support for
cross-compilation of binaries, specification of target platforms and
Python versions when creating wheel files, etc.
Opting to retain the status quo for now allows us to make progress on
improved metadata publication and binary installation support, rather than
having to delay that awaiting the creation of a viable metabuild framework.
Appendix E: Rejected features
=============================