[Distutils] Major update to the metadata 2.0 draft PEPs

[PJ Eby]

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.