At 01:10 PM 8/2/2010 +0200, Tarek Ziadé wrote:
I don't have a specific example in mind, and I must admit that if an application does the right thing (provide the right configuration file), this activate feature is not useful at all. So it seems to be a bad idea.
Well, it's not a *bad* idea as such; actually, having conventions for such configuration, and libraries that help to implement the convention are a *good* idea, and I support it. I just don't think it makes much sense to *impose* the convention on the app developers; there are, after all, use cases that don't need the extra configuration.
Setuptools was mainly designed to support the "application plugin directory" model for invasive sorts of plugins, and the "global plugin availability" model for the kind of plugins that a user has to explicitly select (e.g. file type converters, special distutils commands, etc.). However, there are definitely use cases for "user-configured plugins", and the apps that do it generally use some sort of configuration file to identify which entry points they'll actually use.
IOW, have entry points like setuptools provides, but in a metadata field instead of a entry_points.txt file.
May I suggest, then, that we keep entry_points.txt, but simply provide a summary in PKG-INFO? (i.e., list the groups and names provided)
This would still make it easy for human browsing/discovery of entry points on PyPI, but it would allow easy forward/backward compatibility between setuptools and distutils2, while also providing faster lookup of entry points (because you can skip distributions that don't have an entry points file, vs. having to parse *every* PKG-INFO file).
Or to put it another way, when I implement PEP 376 support in setuptools 0.7, I'll only have to change the name of the .egg-info directory and copy the entry point summary into PKG-INFO. And, even more to the point, people who define entry points with distutils2 will then be able to have them work with setuptools-based projects, and vice versa, helping to smooth the transition.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
