[Distutils] Adding entry points into Distutils ?

Doug Hellmann 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  
> side.
> 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.
>> Doug
> -- 
> Tarek Ziadé | http://ziade.org

More information about the Distutils-SIG mailing list