[Distutils] setup.cfg new format proposal

[Tarek Ziadé]

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.


>
>> do I need to install a package to gets its metadata ?
>
> This is an important use case.  It is orthogonal to defining packages
> with static meta data.

Sure. but both can exist. although It would require a flag in
setup.cfg indicating that
it is not standalone. e.g. doesn't provides all metadata without
requiring to execute some
code in the distribution.

If the flag is not present, you know you can work with setup.cfg alone.


> Somewhat. I think the main concern though is to get the meta data
> without installing.

Well, without running the setup.py code at the minimum, to extract the metadata
if they are platform-dependant. Which can start to happen more and
more the day we add the famous "requires" in the metadata.

For instance, how can I say that I need simplejson only if it's Python
2.5 or above ?

People will have to download the package and run something to know it,
where they could just read the setup.cfg file.

The simplejson dependency will appear at PyPI *only* if the person that ran
the register command used python 2.5 when he did... that's a problem indeed.

Security-wise, if the micro-language is restricted to string comparisons,
with a restricted list of variables, people and tool will be able to query
setup.cfg with no risk.

>
> In any case, I think a sufficiently large percentage of cases can be
> handled without logic in the setup.cfg.

yes

>>> I agree that more background and motivational information would be
>>> very helpful, as would some real world examples. I know that >90%
>>> (maybe 99% :) of the packages I distribute don't adapt to their
>>> execution context (beyond what distutils does internally) or need
>>> anything but meta data.
>>
>> That's why you could push your fields in the static setup.cfg.
>>
>> (and probably have an 'empty' setup.py file)
>
> Yup. Don't get me wrong. I'm in favor of being able to define packages
> with static meta data. I just don't consider configuration files with
> logic in them to be static. :)
>

Let's call it differently then, because if we want static metadata,
we will have to provide that logic for the 1% that needs it.

In any case, is such a feature is a problem for the 99% left ?

You could still add your metadata in the [setup] section and
never use that feature.