[Distutils] Changing the "install hooks" mechanism for PEP 426
vinay_sajip at yahoo.co.uk
Thu Aug 15 18:36:34 CEST 2013
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.
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.
> 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).
More information about the Distutils-SIG