[Distutils] Adding entry points into Distutils ?

[Tarek Ziadé]

On Tue, May 5, 2009 at 1:57 AM, Ian Bicking <ianb at 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.

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