plugin mechanism for packaging itself?
I would like to be able to add a command to packaging for all packages, not just my own. This is a mechanism that would stay out of the way of other packages. 1. Distribute a submodule of the namespace package 'packaging_hooks'. 'packaging_hooks.yourpackage' where 'yourpackage' is the pypi name of the package providing the hook 2. Include in the submodule a dictionary COMMANDS={'command_name':'class name' or class} and __all__ = ['COMMANDS', ...] Packaging calls pkgutil.iter_modules(prefix='packaging_hooks.') to import all the submodules of packaging_hooks, looking for COMMANDS= and resolving the dotted name of the command class if the value is not already the command class. This would only be a plugin mechanism for packaging itself, not a general-purpose replacement for entry_points.
On Tue, Jun 12, 2012 at 11:33 PM, Daniel Holth
I would like to be able to add a command to packaging for all packages, not just my own. This is a mechanism that would stay out of the way of other packages.
1. Distribute a submodule of the namespace package 'packaging_hooks'. 'packaging_hooks.yourpackage' where 'yourpackage' is the pypi name of the package providing the hook 2. Include in the submodule a dictionary COMMANDS={'command_name':'class name' or class} and __all__ = ['COMMANDS', ...]
Packaging calls pkgutil.iter_modules(prefix='packaging_hooks.') to import all the submodules of packaging_hooks, looking for COMMANDS= and resolving the dotted name of the command class if the value is not already the command class.
This would only be a plugin mechanism for packaging itself, not a general-purpose replacement for entry_points.
Namespace packages are not meant to be a plugin mechanism, and having the stdlib violate this principle would be setting a horrible precedent. Please don't.
Horribly convenient? Entry points already import every __init__.py at the root. This would in most cases be looking in a single directory, instead of iterating over every distribution most of which aren't providing any kind of plugin at all. Why not, apart from the occasional name clashes and only supporting one version of each plugin provider?
On Wed, Jun 13, 2012 at 11:58 AM, Daniel Holth
Horribly convenient? Entry points already import every __init__.py at the root.
What?
This would in most cases be looking in a single directory, instead of iterating over every distribution most of which aren't providing any kind of plugin at all. Why not, apart from the occasional name clashes and only supporting one version of each plugin provider?
It turns the entire concept of a namespace package on its head: the point of the namespace is to reduce conflicts and clarify ownership, not the other way around.
participants (2)
-
Daniel Holth
-
PJ Eby