[Distutils] PEP 390 - new format from setup.cfg

[Tarek Ziadé]

On Mon, Oct 12, 2009 at 6:10 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> If you don't have tuples or <, >, etc, it seems like something like
> "Python version 2.6 or higher" is hard to express.  You'd have to
> enumerate 2.6, 2.7, and speculate on 2.8 and 2.9.

python_version not in '2.3,2.4,2.5'

(it's not optimal, but enough I guess, until PEP 386 is accepted)

> One use case for the current setup.cfg is for extensions, like
> generating Sphynx documentation.  Those extensions can sometimes take
> quite a lot of options, so they are best when partitioned into their
> own section.  I'm also not sure whether [metadata] is intended to have
> extensible variables, or a fixed set of variables.

The variables are fixed so it works with a vanilla python and doesn't
require anything else
to run. Having extensible variables would break that idea and would just
make people move code they use to have in setup.py in another place imho.

>> No because we might need to define extra options in setup()
>> that are not part of the metadata, like what is required the for the
>> sdist command
>> (package_data, scripts, package, etc)
>
> OK, so setup.cfg is for generating PKG-INFO, but installing a package
> still involves running setup.py and some maybe-declarative code in
> there.
>

Yes, this is restricted to the Metadata fields.


>> How would you define/provide "features" here ?
>
> I'm not sure.  With Setuptools the equivalent is "extras", like:
>
> setup(name='foo',
>    extras_require={'xmlrpc': ['lxml']})
>
> Then if you do "easy_install foo[xmlrpc]" (or somehow require
> foo[xmlrpc]) it will also install/require lxml.
>
[...]
>  ...
>
> So, since the result involves multiple sections it wouldn't naturally
> map to what you are proposing.

That could be done I think as long as the extras are not calculated by
third-party code.

Let's say, we define an 'extras' variable, which value can be provided
when interpreting setup.cfg.

If could be described like this :

[metadata:'xmlrpc' in extras]
requires = lxml

The part that is unclear to me is how to list the extras a setup.cfg file has.

>> Right, this needs to be defined. I would be in favor of the latter, to
>> stay ConfigParser
>> compatible.
>
> You still have to define how options are combined from multiple
> sections, and what the resulting value is from the API.  That is, if
> you have:
>
>    [metadata]
>    requires = Foo
>        Bar
>
>    [metadata:python_version == '2.4' or python_version== '2.3' or
> python_version=='2.2']
>    requires = BackwardCompat
>
> Then what is the ultimate value of "requires"?  Is it
> "Foo\nBar\nBackwardCompat" or ["Foo", "Bar", "BackwardCompat"], or
> [Requirement.parse("Foo"), Requirement.parse('Bar"),
> Requirement.parse("BackwardCompat")].
>
> And given other variables (ones that perhaps distribute doesn't even
> know about) how are they combined?

Right, this needs clarification. In any case, I think using multiline
is a bad idea
because it'll break RCF 232 compatibility for the long_description field.

So i've updated the PEP with ',' separator.

>>> Is there a way to eliminate values?  Right now, for instance, if you
>>> have "[build] home = /foo" in a distutils.cfg, there's no way to unset
>>> that.  I'd like to see this functionality included.  Perhaps to delete
>>> a specific value, but the simpler case of deleting a variable is
>>> really all I want.
>>
>> Do you have a syntax in mind for this ?
>
> Well, the way I added more meta-operations in Paste Deploy (which uses
> ConfigParser) was to mess with the variable names.  So maybe:
>
>    [metadata:python_version=="2.5"]
>    del requires = Foo
>
> It might have a value to delete a specific value (or line) from that
> "requires" variable, or if empty it would clear that variable.  Since
> ConfigParser doesn't order the variables, it would delete them from
> "earlier" sections, not the current section.  This requires defining
> what makes a section "earlier".  Or maybe it would delete "Foo" from
> whatever the value of requires ends up being, or if you do "del
> requires =" would make that section provide the only value for
> requires.

That makes sense. It completes what we can do.

Also, I've discussed with MAL about this PEP, and he came up with the idea
that the conditions should be pushed in PKG-INFO as well. See
the latest change in PEP 390.

Tarek