On Tue, May 5, 2009 at 1:57 AM, Ian Bicking <[email protected]> wrote: > 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
