[Distutils] Adding entry points into Distutils ?

Tarek Ziadé ziade.tarek at gmail.com
Tue May 5 14:15:40 CEST 2009


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.

>> 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 ?


>>
>> And an entry point that would be "disabled" is an entry point that is not
>> used
>> from the application A point of view, but might be used in the application
>> B.
>
> But if it's not being used by A, why should A see it at all?

A, B or any app can browse all entry points. Entry points are defined
by the (group, name)
couple.

Basically if I want to create a pluggable feature called "myfeature",
the group will be
"myfeature" and plugins that implement that feature will register
themselves under that group.

Then my application will browse and consume entry points for the group
"myfeature" and do
whatever they want with them.

In pseudo code:

   >>> plugins = iter_entry_points(group="myfeature")

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.

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