On Sat, Feb 16, 2013 at 3:27 AM, Erik Bray <erik.m.b...@gmail.com> wrote:
> TL;DR, strong -1 on the stdlib "getting out of the build business".
> Also as I think Nick already mentioned one of the wins of
> Setup-Requires-Dist is to have a standard way to bring in extra build
> requirements (such as bento) so if we have better support for a
> feature like that it's not necessary to "bless" any preferred tool.
I've described below where I personally hope we can get to by the time
of Python 3.4.
Please, if anyone has any comments on the below, send them to me via
private email. I am only publishing this half-baked version to allay
any concerns people may have that distutils itself might be going away
in the foreseeable future (such concerns are perfectly understandable,
given the many harsh things that have been said about distutils and
the use of setup.py to drive the build process).
(I plan to flesh this out further before the packaging & distribution
mini-summit at PyCon US, but it already reflects the general scheme I
had in the back of my mind when I decided to step up as BDFL-delegate
for Daniel's three PEPs related to the wheel format. There are
obviously lots of details to be worked out on distutils-sig and
catalog-sig, but the big advantage it has over the approach tried with
distutils2 is that individual projects shouldn't have to change much
of anything - this scheme is designed to work so long as I can
convince at least the setuptools, distribute, distutils2, pip, bento
and zc.buildout developers to support it. End users would just need to
update to recent versions of their preferred tools or, in the case of
current users of plain distutils, upgrade to setuptools/distribute or
use the "pip wheel" subcommand to get wheel support in older versions
of Python)
Components:
Archiver: creates sdist source archives for distribution
Builder: creates wheel binary archives for installation or distribution
Uploader: tool for publishing to PyPI and private index servers
Installer: retrieves archives (and their dependencies) and
installs them on a target system
Proposed flow for source distribution:
Development System:
-> Source checkout
-> Installer -> Setup-Requires-Dist dependencies
-> Archiver -> sdist
-> Uploader -> PyPI (or private index server)
Target System:
-> Installer -> sdist + Setup-Requires-Dist dependencies
-> Builder -> wheel
-> Installer -> installed software + Requires-Dist dependencies
Proposed flow for binary distribution:
Development System:
-> Source checkout
-> Installer -> Setup-Requires-Dist dependencies
-> Archiver -> sdist
-> Builder -> wheel
-> Uploader -> PyPI (or private index server)
Target System:
-> Installer -> installed software + Requires-Dist dependencies
Standard library (3.4):
distlib: tools to create Archivers, Uploaders, Builders and Installers
pydist: Uploader/Installer CLI
distutils: Archiver/Builder CLI (via setup.py)
(setup.py will also continue to function as a limited
Uploader/Installer CLI)
Alternate Archiver/Builder tools:
setuptools, distribute, distutils2, bento (and various custom
distutils derivatives)
Alternate Installer tools:
pip, easy_install, zc.buildout
The pydist CLI would likely be deliberately limited to installation
from wheel binary archives. The officially recommended approach to
supporting installation from sdist on systems which do not provide pip
preinstalled would then be "pydist install pip".
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
