[Distutils] Adding entry points into Distutils ?

[Ian Bicking]

On Mon, May 4, 2009 at 6:46 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:

> Hello
>
> I am making a separate email for this topic to make sure no one misses it.
>
> There are *many* benefits of adding entry points into Distutils. In
> fact, adding a plugin system in there,
> will help make the commands more extendable and therefore will help us
> in the long term to remove things
> out of Distutils.
>
> So any strong opinion against them ?
>

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?
* I'm uncomfortable with the way entry points are scanned.  I haven't looked
close enough to back it up with numbers, but I think there's a noticeable
performance degradation when the number of installed packages becomes
large.  (Given the algorithm this would be expected.)
* Scanning for entry points by name makes me uncomfortable, but I feel like
the API kind of encourages it.
* 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.
* 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.
* Entry points that provide functionality to the installation system itself
make me very uncomfortable, except insofar as they describe the package.
[console_scripts] is okay, but some of the other Setuptools extension points
bother me because of the self-referential nature, e.g., egg_file_writers.



-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090504/9c36bc69/attachment-0001.htm>