On Mon, May 4, 2009 at 6:46 PM, Tarek Ziadé <ziade.ta...@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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
