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

[P.J. Eby]

At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote:
>If you look at the proposal, it is really just about adding a
>new data store to manage a certain package type called "plugins".
>Next time around, someone will want to see support for "skins" or
>"themes". Then perhaps identify "script" packages, or
>"application" packages, or "namespace" packages, or "stubs", etc.
>All this can be had by providing this kind of extra
>meta-information in the already existing format.

If by "existing format", you mean "entry points", then yes, that is 
true.  ;-)  They are used today for most of the things you listed; 
anything that's an importable Python object (module, class, function, 
package, constant, global) can be listed as an entry point belonging 
to a named group.  Heck, the first code sample on Nullege for 
iter_entry_points is some package called Apydia loading an entry 
point group called "apydia.themes"!

Seriously, though, PEP 376 is just setuptools' egg-info under a 
different name with uninstall support added.  And egg-info was 
designed to be able to hold all those things you're talking 
about.  The EggTranslations project, for example, defines 
i18n-support files that can be placed under egg-info, and provides 
its own APIs for looking those things up.  Applications using 
EggTranslations can not only have their own translations shipped as 
plugins, but plugins can provide translations for other plugins of 
the same application.  (I believe it also supports providing other 
i18n resources such as icons as well.)

So, it isn't actually necessary for the stdlib to provide any 
particular support for specific kinds of metadata within PEP 376, as 
long as the PEP 376 API supports finding packages with metadata files 
of a particular name.  (EggTranslations uses similar APIs provided by 
pkg_resources.)

However, since Tarek proposed adding a stdlib-supported plugins 
feature, I am suggesting it adopt the entry_points.txt file name and 
format, to avoid unnecessary API fragmentation.


>If we add a new extra file to be managed by the package
>managers every time someone comes up with a new use case,
>we'd just clutter up the disk with more and more CSV file
>extracts and make PEP 376 more and more complex.

The setuptools egg-info convention is not to create files that don't 
contain any useful content, so that their presence or absence conveys 
information.  If that convention is continued in PEP 376, features 
that aren't used won't take up any disk space.

As for cluttering the PEP, IMO any metadata files that aren't part of 
the "installation database" feature should probably have their own PEP.