
On Wed, Mar 27, 2013 at 6:42 AM, Erik Bray <erik.m.bray@gmail.com> wrote:
I pretty much agree with you on all of this, but I don't think the question should be ignored either--avoiding this question is one of the things that got previous packaging reform efforts into trouble. Though the agreement to treat "build" and "installation" as two different stories mitigates the issue this time around. In any case it's sort of off topic for this thread so I'll bring it up again elsewhen. One thing I see as a possible short-term solution is to still rely on some version of distutils as a build tool *only*. But it would still be nice to have some easy way to standardize "in-place" installation regardless of how extension modules get built.
That's exactly the interim solution I have in mind: for the moment, the "archive system" will be "python setup.py sdist" in an appropriate location and the "build system" will be "python setup.py bdist_wheel". Both will be modelled on pip's current behaviour when installing from sdists - the difference will be in the explicit invocation of the separate steps, rather than handling the whole chain with "setup.py install". Longer term I want to make setup.py optional even for source installs, but that requires further enhancements to the metadata. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia