[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