On Sat, Feb 16, 2013 at 3:27 AM, Erik Bray
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 | ncoghlan@gmail.com | Brisbane, Australia