![](https://secure.gravatar.com/avatar/4021eb3a9a363520e27c736cec6905e6.jpg?s=120&d=mm&r=g)
On May 5, 2009, at 11:05 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 4:29 PM, Doug Hellmann <doug.hellmann@gmail.com> wrote
a configuration file that reunites all entry points an application uses. For the Atomisator example:
[atomisator.reader] rss = somepackage.somemodule:MyPluginClass
Yes! We can figure out the exact spelling, but we're talking about the same thing now. If we use dotted notation all the way ("somepackage.somemodule.MyPluginClass") then it's simple to just import the thing directly.
I think is simpler with the "somepackage.somemodule:MyPluginClass" notation
Good point, I was remembering the import syntax incorrectly.
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
That sounds good.
The only caveat I see though, is that the host app has to know the exact location of each plugin in the code of the third party app, whereas entry points provide this information through the discovery API.
True. On the other hand, that encourages standard locations like "mylib.yourapp.entry_point" and "mylib.anotherapp.entry_point". I think most of my concerns about the global registry are taken care of by the fact that "discovering" a plugin doesn't involve any imports of unknown code. I still prefer per-app, explicit configuration of entry points, and think we could build a system to support that. I would like to see *some* variation of this in the standard library, though, because I have several uses for it. Doug