On 20 July 2013 01:20, Brett Cannon <brett@python.org> wrote:
If the long-term plan is to bless setuptools then go for the bundling, but if that decision has not been made yet then bundling may be premature if the bundling of pip with Python moves forward.
PEP 426 is currently looking at blessing a subset of *setup.py* commands as an interim build system, without blessing any particular tool. At the moment, I don't list any required arguments for the individual commands, but I'm starting to think that needs to change. It's probably worth looking at the common subset currently supported by setuptools and d2to1, and figuring out which can be left out as "you need to know which build system the project is using and invoke them appropriately" and which we want to standardise. Something else I see as potentially getting blessed is "assume setuptools" as a fallback option for projects that don't publish 2.0+ metadata (part of which will include providing a pre-generated dist-info directory in the sdist, as well as a way to indicate how to generate the metadata in a raw source tarball or VCS checkout) That's why I'm OK with the idea of the pip team *only* supporting installing from wheels if setuptools isn't installed, and treating setuptools as an implicit install_requires dependency if it is necessary to install from a source distribution. Resolving all of this formally is a ways down the todo list though, and the problem of source-based (rather than wheel-based) integration is one of the big reasons I see nailing down the metadata 2.0 spec as a process that still has several months left to run rather than being "almost finished". At the moment I *don't* see a good projects-can-use-any-build-system-they-like story for the path from a Python project tarball to a built and published Fedora or RHEL RPM, and that concerns me (since making it practical to almost fully automate that chain is one of my goals). If you had asked me a couple of months ago, I would have said I thought we could get away with deferring the answers to these questions (and PEP 426 is currently written that way), but I now think we're better of continuing with the setuptools-compatible metadata approach for the time being, and taking the time to get metadata 2.0 *right* for both binary and source distribution, rather than having to follow it up with a metadata 2.1 to fix the source distribution side of things. Getting PEP 427 (wheel 1.0) approved reasonable quickly was necessary to provide a successor to eggs that pip was willing to adopt, but I no longer think there's the same urgency for the metadata 2.0 standard in PEP 426 (ever since Daniel realised that wheels could work just as a well with setuptools compatible metadata as they could with a new metadata standard). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia