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

Tarek Ziadé ziade.tarek at gmail.com
Mon Oct 12 11:45:56 CEST 2009


On Mon, Oct 12, 2009 at 2:29 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> The grammar in "Context-dependant sections" indicates possible EXPR
> values.  Because the "in" operator is supported, I would assume that
> tuples should also be allowed.

"in" here is restricted to string. It was added so we could write things like:

'linux' in sys_platform  (where sys_platform can be linux2)

I'll add a note on that.

>
> One aspect of the current setup.cfg is that it supports multiple
> sections, for different setup.py commands or components.  This gives a
> kind of namespacing.  I assume, but it isn't that specified, that any
> section (not just "metadata") will be parsed the same way?

I guess yes, even if I don't see a use case yet for that.

>
> Presumably setup.py will just contain an empty call to setup()?  (I
> assume at least setup.py will be allowed for, for backward
> compatibility, even if it is not required.)

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)


>
> I believe this does not include the concept of extra requirements.
> Possibly it could as a side-effect of some variable available to the
> language.  Like:
>
>  [metadata:'xmlrpc' in features]
>  requires = lxml
>
> Sets and the & operator could be useful for this.

How would you define/provide "features" here ?

>
> The way variables are handled is unclear.  Presumably all variables
> are cumulative.  But given:
>
>  requires = Foo
>  requires = Bar
>
> What is the value of "requires"?  A list, a value with newlines?
> Presumably you could also do:
>
>  requires = Foo
>      Bar
>
> Anyway, we're diverging from INI semantics at this point, so it needs
> to be specified how it works.

Right, this needs to be defined. I would be in favor of the latter, to
stay ConfigParser
compatible.

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

Tarek


More information about the Distutils-SIG mailing list