[Distutils] Comments on PEP 426

[Daniel Holth]

On Wed, Sep 4, 2013 at 9:44 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 4 September 2013 23:32, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 4 September 2013 14:27, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> I was under the impression pip *already* forced the use of setuptools
>>> (to ensure "--record" is available), so why would "pip wheel" provoke
>>> any more bug reports than "pip install"?
>>
>> It won't, but at the moment the reports are likely to be that *pip* is
>> where the error lies. We're saying that such reports will in future be
>> redirected at the project. That is the change. (It may be that it's
>> simply changing "can't fix" to "won't fix" - I don't know how
>> traditionally pip deals with such reports, if indeed it has ever had
>> any).
>>
>> There's no point in worrying though until we have evidence of such a
>> project actually existing. If no-one wants to try to check "likely
>> candidates" in advance, let's just wait for the bug reports if any.
>
> More accurately, the response will still be "let's investigate and see
> exactly what's going wrong". The only real change is that "the project
> should change its setup.py to cope with the setuptools
> monkey-patching" will be a more likely resolution from the
> distribution tools side. Bugs in pip and setuptools are still a
> possibility, and modifying pip to not *need* the setuptools
> monkey-patching is still highly desirable. It's just not a blocker for
> anything else :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

Let's review the proposed MEBS "meta build system" design which would
provide a way for sdists to declare their build system and produce
something that can be installed. I haven't implemented it yet mainly
because packaging is not my only hobby:

- each installed build system registers a .detect(path) method that
determines whether it can build a particular unpacked sdist
- the build+installer unpacks an sdist
- the first build system where .detect() returns True is instantiated.
(A configuration file can determine the precedence of installed build
systems.)
- the build object has a .metadata() method returning a dict of the
sdist's metadata 2.0
- the build object has a .build() method that produces a wheel
- todo development/in-place builds
- todo how is the requested build system declared when no installed
build system recognizes the package
- todo plenty

- the installer installs the new wheel

Critically "setup.py install" is no longer needed as a feature of new
build systems. The build system can focus on building and the
installer on installing, simplifying both.

A second important feature of this design is that MEBS does not always
respect the package's declared build system, for example providing a
way for setuptools to be used for distutils packages as it is today,
or perhaps for distil to be used but only for those packages for which
it is known to work.

The current pip "always import setuptools" build process would be the
first MEBS plugin.