[Python-Dev] PEP 376 proposed changes for basic plugins support

[P.J. Eby]

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.