At 01:25 PM 6/15/2010 +0900, David Cournapeau wrote:
On Tue, Jun 15, 2010 at 10:36 AM, P.J. Eby email@example.com wrote:
As I said above, "it *also* scales better for performance" -- i.e., it's a secondary concern.
Â The #1 reason for separating metadata files is that it makes the addition of new metadata much easier than maintaining a single monolithic format.
Do you still think it is true today ? I am asking because AFAIK, there aren't many packages besides setuptools which use those metadata ?
That depends on what you mean "besides setuptools". Entry points, for example, are used by various apps and frameworks that implement plugins, and these in turn are used by app and plugin developers. There's also a package (EggTranslations I think?) that uses metadata files for i18n discovery, allowing plugins to provide translations for an app, or translations for other plugins.
So, it's true that it's not very common that a library or app would directly use metadata files -- in general, you'll go through an intermediary such as setuptools or EggTranslations... or even a third level, such as an app framework that then uses setuptools internally to implement a plugin API.
I don't mean to criticize the design, just to see if you would do things differently today.
Oh, many things. But separating metadata files is definitely NOT one of them.
As you might notice, PEP 376 and Distutils2 build even further on this pattern, with roughly the same rationale(s).