[Distutils] setup.cfg new format proposal

Tarek Ziadé ziade.tarek at gmail.com
Fri Sep 11 17:49:51 CEST 2009


On Fri, Sep 11, 2009 at 5:36 PM, Jim Fulton <jim at zope.com> wrote:
> On Fri, Sep 11, 2009 at 11:14 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> 2009/9/11  <exarkun at twistedmatrix.com>:
>>> On 02:33 pm, ziade.tarek at gmail.com wrote:
>>> I'm a little skeptical about creating a new mini language (particularly one
>>> with branching) for setup.cfg,
>
> Me too.
>
>>> but I haven't really been paying close
>>> attention to this discussion.
>
> Me neither. :)
>
>>>  Still, it might be good to give a brief
>>> summary of the justification for this someplace.  Maybe you were already
>>> planning to do that.
>>
>> The idea is to be able to get with setup.cfg all the metadata without running
>> any code from the distribution, and without installing it.
>>
>> Which is possible for most cases. (if not possible, setup.py  can still be used)
>>
>> the mini-language is to be able to adapt these metadata depending on
>> the execution context. I'll add a doc somewhere.
>
> Is that really necessary?  I mean, if you have to adapt the meta data
> to the execution context, maybe you should fall back to writing a
> setup.py.

The main background motivation is the future adding of
"install_requires" in PEP 345.

So you can for example define a list of dependencies that changes wether
you are under windows or linux, etc..

The second motivation is : why do I need to run some code to get the
metadata fields ?
do I need to install a package to gets its metadata ?

In 99% of the cases that would'nt be necessary.

try to run this with lxml source tarball:

$ python setup.py --name

I don't know what it is doing, but a whole lot more that what it is
suppose to do
just to let me know the 'name' metadata.

So if name was in setup.cfg, it would be better.

>
> 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)

I will prepare a document summarizing. Maybe a PEP would be required then
if it's not an obvious change.


Tarek


More information about the Distutils-SIG mailing list