On May 5, 2009, at 8:15 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 1:57 PM, Doug Hellmann
<doug.hellm...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
