[Distutils] Static metadata using setup.cfg

[Tarek Ziadé]

On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith<eric at trueblade.com> wrote:
> Tarek Ziadé wrote:
>>
>> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<chris at simplistix.co.uk>
>> wrote:
>>>
>>> Tarek Ziadé wrote:
>>>>
>>>> - an extra function called "long_description", to be able to point a
>>>> file for the long description field
>>>
>>> I can't comment on the others, but this is unnecessary. Why do you need
>>> more
>>> than:
>>>
>>> long_decription="some lump of text"
>>>
>>> or
>>>
>>> long_description_path ="path/relative/to/directory/containing/setup.py"
>>>
>>> ...with it being an error for both to be specified?
>>>
>>> cheers,
>>>
>>
>> The practice in the community is to create the long_description field
>> using a separate reStructuredText file
>> and reaching it in setup.py like this for example:
>>
>> long_description = open('README.txt').read()
>>
>> Having a callable that provides this feature in the template allows
>> writing:
>>
>> """
>> [setup.cfg]
>>
>> long_description: {$ long_description('README.txt') $}
>> """
>>
>> Thus avoiding to write anything in setup.py for that particular case.
>> the callable could be called "read_file()" maybe, so it's clearer.
>>
>> long_description_path can't be added in the final PKG-INFO because
>> we want a self-contained metadata static file that doesn't require an
>> extra resource (like an external file)
>>
>> Whereas having a file path in setup.cfg.in is acceptable, as long as
>> the resulting setup.cfg
>> contains everything needed to get the metadata of the package without
>> further depenencies.
>>
>> so if by the time setup.cfg.in is compiled, the path cannot be found,
>> the field will have its value set to "UNKOWN" in setup.cfg
>
> Which all points out that it's setup.cfg that is the static metadata, and
> that you can generate it any way you want. If you want to use m4, use m4. If
> you want to use python, use python. If you want to have some makefile driven
> approach, or use autoconf, or whatever, do that.
>
> setup.cfg should be entirely static except for some simple if-then-else
> logic involving versions, as Tarek has described earlier. That is, it should
> only contain logic that needs to be decided on the platform where the
> installation is taking place. This is basically what RPM provides.
>
> Any other logic, in particular logic used solely for building setup.cfg,
>  should be outside the scope of this system, because you can use any tool at
> all for it.
>

So you are suggesting that setup.cfg includes the "if/else" logic
instead of having it
in a "setup.cfg.in" file ?

In that case, if we want to keep a configparser-compatible file, we
need to find another
way to express these if/else parts, which will probably lead to a
complex, non natural
syntax.

Having a "setup.cfg.in" file with if/else logic in it, to build the
setup.cfg independanlty
from the package code, using a function provided by python's stdlib, allows
us to have a simple syntax.

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org | オープンソースの岩！