On Mon, May 4, 2009 at 6:46 PM, Tarek Ziadé <ziade.tarek@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