On Tue, Feb 19, 2013 at 6:42 AM, Nick Coghlan
Nothing in the PEP is particularly original - almost all of it is either stolen from other build and packaging systems, or is designed to provide a *discoverable* alternative to existing setuptools/distribute/pip practices (specifically, the new extension mechanism means things like entry points can be defined in the standard metadata files without python-dev needing to get involved).
FWIW, I actually think this is a step in the wrong direction relative to eggs; the ability to add new metadata files is a useful feature for application frameworks. For example, the EggTranslations project uses egg metadata to implement resource localization plugins. It lets you have an application with plugins that either contain their own translations, contain multiple translations for another plugin, a single language translation for an assortment of plugins, etc. These kinds of runtime-discovery use cases haven't seen much attention in the metadata standard discussion. On one level, that's fine, because it makes sense that distribution-provided metadata should be parseable by all tools, and that at build/download/install time the performance and ease-of-use favor a single file approach. That does not mean, however, that the presence of other files is bad or should be deprecated. IMO, metadata that see significant runtime use independent of the core metadata *should* appear in their own files, even if redundant.