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

[Nick Coghlan]

On 15 Aug 2013 12:27, "PJ Eby" <pje at telecommunity.com> wrote:
>
> 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.

But if we're only going to validate it via hooks, why not have the "mapping
of names to export specifiers" just be a recommended convention for
extensions rather than a separate exports field?

pydist.install_hooks, pydist.console_scripts, pydist.gui_scripts would then
all be conventional export groups.

pydist.prebuilt_commands would be non-conventional, since the values would
be relative file paths rather than export specifiers.

As an extension, pydist.extension_hooks would also be non-conventional,
since it would define a new namespace, where extension names map to an
export group of hooks. A separate export group per hook would be utterly
unreadable. That's why I'm still inclined to make this one a separate top
level field: *installers* have to know how to bootstrap the hook system,
and I like the symmetry of separate, relatively flat, publication and
subscription interfaces.

Cheers,
Nick.

>
>
> > 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.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130815/83bd3b2c/attachment.html>