On Wed, Jan 1, 2014 at 9:39 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 1 Jan 2014 10:33, "PJ Eby" <p...@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.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
