[Distutils] Changing the "install hooks" mechanism for PEP 426

[PJ Eby]

On Thu, Aug 15, 2013 at 12:36 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> PJ Eby <pje <at> telecommunity.com> writes:
>> than nested.)  So I would suggest that an export can either be an
>> import identifier string, *or* a JSON object with arbitrary contents.
> [snip]
>> Given how many use cases are already met today by providing
>> import-based exports, ISTM that they are the 20% that provides 80% of
>> the value; arbitrary JSON is the 80% that only provides 20%, and so
>> should not be the entry point (no pun intended) for people dealing
>> with extensions.
>
> The above two statements seem to be contradictory as to the value of
> arbitrary JSON.

I don't see a contradiction.  I said that the majority of use cases
(the figurative 80% of value) can be met with just a string (20% of
complexity), and that a minority of use cases (20% of value) would be
met by JSON (80% of complexity).

This is consistent with STASCTAP, i.e., simple things are simple,
complex things are possible.

To be clear: I am *against* arbitrary JSON as the core protocol; it
should be only for "complex things are possible" and only used when
absolutely required.  I think we are in agreement on this.


> I think the metadata format is a communication tool between
> developers as much as anything else (though intended to be primarily
> consumed by software), so I think KISS and YAGNI should be our watch-words
> (in terms of what the PEP allows), until specific uses have been identified.

+100.


>> That would make it easier, I think, to implement both a full-featured
>> replacement for setuptools entry point API, and allow simple
>
> What do you feel is missing in terms of functionality?

What I was saying is that starting from a base of arbitrary JSON (as
Nick seemed to be proposing) would make it *harder* to provide the
simple functionality.  Not that adding JSON is needed to support
setuptools functionality.  Setuptools does just fine with plain export
strings!

I don't want to lose that simplicity; the "export string or JSON"
suggestion was a compromise counterproposal to Nick's "let's just use
arbitrary JSON structures".


> I think the thing here is to identify what the components in the build
> system would be (as an abstraction), how they would interact etc. If we look
> at how the build side of distutils works, it's all pretty much hardcoded
> once you specify the inputs, without doing a lot of work to subclass,
> monkey-patch etc. all over the place. It's unnecessarily hard to do even
> simple stuff like "use this set of compilation flags for only this specific
> set of sources in my extension". In any realistic build pipeline you'd need
> to be able to insert components into the pipeline, sometimes to augment the
> work of other components, sometimes to replace it etc. and ISTM we don't
> really know how any of that would work (at a meta level, I mean).

I was assuming that we leave build tools to build tool developers.  If
somebody wants to create a pipelined or meta-tool system, then
projects that want to use that can just say, "I use the foobar
metabuild system".  For installer-tool purposes, it suffices to say
what system will be responsible, and have a standard for how to invoke
build systems and get wheels or the raw materials from which the wheel
should be created.

*How* this build system gets the raw materials and does the build is
its own business.  It might use extensions, or it might be setup.py
based, or Makefile based, or who knows whatever else.  That's none of
the metadata PEP's business, really.  Just how to invoke the builder
and get the outputs.