On Tue, May 5, 2009 at 1:57 AM, Ian Bicking
Not strong, but I have a few issues with how they are currently defined:
* There's the issue of activated and unactivated eggs, of course, but I guess that will be moot since there's no activation with just distutils?
Yes
* There's no idea of explicitly enabling an entry point, simply installing a package makes the entry point show up. Implicit plugins make me uncomfortable.
I don't see entry points as plugins, but rather the registering of a given piece of code, under a unique name. If you add explicit enabling, who will do it ? the package that has the entry point ? The applications that consumes them ? The way I see entry points is "potential" plugins, an application can decide to consume, and turn into a real plugin when it uses it. 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. (unless I misunderstood the concept of "group") So enabling/disabling an entry point and keeping track of the activation state should be done by the host application ihmo.
* There's not much in the way of entry point documentation built into the system. The __doc__ of the entry point objects is one way, but there's no way to document entry point groups.
very good point, -- Tarek Ziadé | http://ziade.org