[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