[Distutils] Adding entry points into Distutils ?
ianb at colorstudy.com
Tue May 5 01:57:31 CEST 2009
On Mon, May 4, 2009 at 6:46 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> 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
* 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...
More information about the Distutils-SIG