[Distutils] Static metadata using setup.cfg

Eric Smith eric at trueblade.com
Tue Sep 8 14:32:02 CEST 2009


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.


More information about the Distutils-SIG mailing list