[Distutils] Adding entry points into Distutils ?
doug.hellmann at gmail.com
Tue May 5 14:41:50 CEST 2009
On May 5, 2009, at 8:15 AM, Tarek Ziadé wrote:
> On Tue, May 5, 2009 at 1:57 PM, Doug Hellmann
> <doug.hellmann at gmail.com> wrote:
>> If I have to "turn on" the plugin, then what benefit does an entry
>> point registry give me?
> I don't understand this sentence, since you say later that you want
> the user to
> manually turn a plugin "on" for an application to soncume it.
I want each application to be configured separately, rather than
having a global registry of plugins. So having a "plugin registry"
*library* in stdlib may make sense (so that apps can build their
registry databases in a consistent way), but automatically registering
entry points just because a package is installed does not.
>>> If you add explicit enabling, who will do it ? the package that has
>>> the entry point ?
>>> The applications that consumes them ?
>> The user who wants the application to consume the plugin.
> I am confused with the role of this "man in the middle". In my mind
> there are plugins on one side,
> and host applications that consumes them if they wish on they other
> Do you have a use case we can share for mutual comprehension ?
I think we have a different view about how the plugins should work.
It sounds like you're advocating a model where all plugins are
registered globally, an application can search the global registry for
plugins based on categories, and then some administrator enables/
disables them locally for each app.
I don't want new functionality available to an application just
because someone has permission to install a package somewhere in the
PYTHONPATH. I would rather have plugins added to an app through an
explicit configuration step of some sort.
> So if A doesn't need the plugins that are under the group "myfeature",
> it will just ignore the entry points
> that are in this group. e.g. ignore the group.
> Maybe A will consume entry_points that are under another group. But I
> have never browsed *all* entry points
> from an application.
That depends on how the database of entry points is maintained, but
I'll grant that point.
> I think the best practice for entry points is to use the most explicit
> group names possible, but having plugins
> that can be consumed by several applications is a win ihmo.
> For instance, if I need to write a specific extensible installation
> script, I'll probably see if I can consume
> zc.buildout recipes through the "zc.buildout.recipe" group.
> Tarek Ziadé | http://ziade.org
More information about the Distutils-SIG