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

[Vinay Sajip]

PJ Eby <pje <at> telecommunity.com> writes:

> I think that as part of the spec, we should either reserve multiple
> prefixes for Python/stdlib use, or have a single, always-reserved
> top-level prefix like 'py.' that can be subdivided in the future.

+1

There's quite a lot of stuff in your post that I haven't digested yet, but 
one thing confused me early on:

> 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 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. 

> 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?

> It's just extensions, IMO.  What else *is* there?  You *could* define
> a core metadata field that says, "this is the distribution I depend on

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).

Regards,

Vinay Sajip