[Distutils] Major update to the metadata 2.0 draft PEPs

[Nick Coghlan]

On 2 Jan 2014 03:59, "PJ Eby" <pje at telecommunity.com> wrote:
>
> On Wed, Jan 1, 2014 at 9:39 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 1 Jan 2014 10:33, "PJ Eby" <pje at telecommunity.com> wrote:
> >> I have only been skimming these so far, will comment more later, but I
> >> just want to mention that for standard extensions, what is the
> >> rationale for not defining e.g. commands as exports?  Or for that
> >> matter, defining hooks as exports?  Both commands and hooks have a
> >> payload that's the same as an export payload, i.e., a reference to an
> >> importable object.  I think it'd be good for them to be defined in
> >> terms of exports in order to reduce duplication of concepts and
> >> implementations, as well as providing a PEP-defined example of how to
> >> use export groups and export names effectively.
> >
> > I believe it was due to the extra layer of nesting they needed - using
> > multiple parallel export groups with different final elements in their
> > dotted names didn't feel right.
> >
> > I guess that indicates a flaw in my initial design for the export
> > definitions though - I agree it would be better if commands and hooks
could
> > be cleanly defined within the exports mechanism, rather than needing
> > separate custom metadata extensions.
>
> If it's a flaw, I'd say it's in my original design of entry points.
> ;-)  Basically, I wanted a way to do -- without XML -- what Eclipse
> does with its "extensions" and "extension points" machinery.  I went
> with a "flat (with dots) is better than nested" concept.
>
> To me, though, this doesn't look terribly complicated (using entry
> points syntax):
>
>     [python.exports.after_install]
>     ComfyChair.plugins = ComfyChair.plugins:install_hook
>
>     [python.exports.after_uninstall]
>     ComfyChair.plugins = ComfyChair.plugins:install_hook
>
> Nor this:
>
>     [python.extensions.after_install]
>     python.exports = pip.export_group_hooks:run_install_hooks
>     python.commands = pip.command_hook:install_wrapper_scripts
>
>     [python.extensions.after_uninstall]
>     python.exports = pip.export_group_hooks:run_uninstall_hooks
>
> (Also, adding hooks to *validate* extensions and exports at build
> and/or install time might be handy.)
>
> Finally, note that if the typical usecase is to define *both* an
> install and uninstall hook, then it might be simpler to just define
> the hook once, as an object with 'after_install' and 'after_uninstall'
> methods.  This avoids the need to register a hook in two groups, and
> in the simplest case people can just make them both module-level
> functions and list the module as the export.

Ah, true - people could provide them as either functions or class methods,
and if we add a new one, only the list of permitted names (and their
signatures) needs to change.

And splitting commands into python.commands and python.commands.gui export
groups would cover the export compatible cases. Since identifying "prebuilt
commands" in the metadata is a new feature without any particularly
compelling justification at this point, I'll likely just leave it out for
2.0.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140102/85f15d31/attachment.html>