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.
_______________________________________________ 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
