On May 5, 2009, at 4:49 AM, Tarek Ziadé wrote:
On Tue, May 5, 2009 at 1:57 AM, Ian Bicking <i...@colorstudy.com>
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.
I don't understand that. I thought the purpose of entry points was to
register code such as plugins so that applications didn't have to be
manually configured. I think I'm with Ian on that one: Explicit is
better than implicit. If I have to "turn on" the plugin, then what
benefit does an entry point registry give me? I could just as easily
provide that information to the application directly.
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.
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.
But if it's not being used by A, why should A see it at all?
Doug
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
