On Tue, May 5, 2009 at 2:41 PM, Doug Hellmann
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.
That is basically how host applications are dealing with entry points: an explicit configuration. The implicit part is just happening when you look for the plugins. Let's take a real example : I am working on a program called Atomisator which can be extended through plugins. For example people can provide a plugin to read data that are located somewhere (like a rss feed), and return a sequence of entries. So in atomisator, I have a configuration file where I decide which plugin to use to read my data: """ [atomisator] reader = rss """ When reading it, Atomisator knows that it needs the "rss" plugin, and will browse in entry points with a specific group called "atomisator.rss". If it finds it, it uses it, otherwise it throws an exception. ("Install it!") That allows people to create their own plugins in separate packages, and use them by tweaking the configuration file. The only think that entry point provided here is an automatic registration at installation time of the "rss" plugins, so my Atomisatior application can discover then load it at run time. So in your way of seeing thing, you'd rather see this registration mechanism at the application level, but the you need to provide specific installation instructions for people that want to add plugins. e.g. "put your package in this /plugins directory" for example. I am advocating that the entry point mechanism is handy because it relies on an existing mechanism : "install your package" and it allows plugin sharing amongst applications. But I see the caveats you are explaining, and I understand them now; So, what if we didn't have these entry points installed globally when the package is installed, but just a configuration file in the host application level to point them ? a configuration file that reunites all entry points an application uses. For the Atomisator example: [atomisator.reader] rss = somepackage.somemodule:MyPluginClass This would let the application consume the plugins pointed by this configuration file and this would remove the implicit part you don't like. I'd be very happy with such a plugin system on my side. And this would fit I think in Distutils needs since we can configure it through three levels of configuration files distutils.cfg, pydistutils.cfg and setup.cfg Tarek -- Tarek Ziadé | http://ziade.org