2009/9/12 P.J. Eby email@example.com:
At 12:28 AM 9/12/2009 +0200, Tarek Ziadé wrote: >
On Fri, Sep 11, 2009 at 7:40 PM, Jim Fulton firstname.lastname@example.org wrote: >
The second motivation is : why do I need to run some code to get the metadata fields ?
Turning the config file into code means you'd be running code. :)
Well that's very different. You will be running a function that is provided in the stdlib, in a vanilla Python, and that will be restricted to string comparisons basically.
In other words, it is more likely to be a translation of setup.cfg into a "localized" setup.cfg.
But in that case, why not just have a 100% static format without any dynamic content whatsoever, and run a "configure.py" or some such (perhaps "distconfig.py") to generate it? Since it's not setup.py, there are no backward compatibility issues, and we can actually get the full benefit of environment-specific configuration (e.g. library locations, etc.).
The benefit of the not-so-static setup.cfg I can see:
1/ If the code used to read setup.cfg knows how to translate a setup.cfg into "a localized" one, given a list of strings that defines the python execution environment
2/ if it is located in the stdlib and is restricted to that usage
it means that we can even provide an XML-RPC service at PyPI so people can query the metadata for their platform with zero download and zero third-party code execution.
I can see a use case of the configure.py file you are describing: prepare the compilation some C Extensions by looking for some libs etc,
But that's something that can already be done with setup.py when you build or install the distribution.
So what would be the metadata field that would require to look for a library location ?