[Distutils] setup.cfg new format proposal

[Tarek Ziadé]

2009/9/12 P.J. Eby <pje at telecommunity.com>:
> At 12:28 AM 9/12/2009 +0200, Tarek Ziadé wrote:
>>
>> On Fri, Sep 11, 2009 at 7:40 PM, Jim Fulton <jim at zope.com> 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 ?