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

[Ian Bicking]

On Mon, Oct 12, 2009 at 11:34 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> 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)

Given the small number of values available, string comparison works
fine in this case.  Is there a situation when the data would be
dependent on a package version other than Python's?

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

It should at least be allowed to have other values with a warning,
similar to keyword arguments to setup() that are unknown.  This lets
the format be forward compatible with new variables.  E.g., if in
Python 2.8 there's a new variable, people can just dump it in.

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

There needs to be some enumeration of extras, yes.  And there really
needs to be more metadata than Setuptools allows for -- extras should
have at least a readable description.  So wherever they are defined,
there should be room for that documentation as well.

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

Oh... long_description -- I forgot about that.  How will that be dealt
with?  I now typically do something like this in setup.py:

  long_desc = open(os.path.join(os.path.dirname(__file__), 'docs',
'index.txt')).read()
  long_desc = long_desc.split('..contents::', 1)[1].strip()
  setup(..., long_description=long_desc)

Keeping the long description in setup.py (or in setup.cfg) is not
something I want to do.  It would be even worse in setup.cfg than it
is in setup.py.  Also ConfigParser eats leading whitespace (I believe
that's also a problem with the PKG-INFO format), which breaks ReST.
(I assume the "register" command does something other than uploading
PKG-INFO to get long_description in place?)

(Come to think of it, I'm not actually sure what we're accomplishing
with this declarative metadata; "setup.py --name" is too minimal, but
some new "setup.py metadata" command that dumps everything isn't hard
to imagine; what are the *real* advantages of this new proposal?  If I
have to use a build process to build my setup.cfg, then absolutely
nothing will be accomplished.  And is the complexity all just because
sometimes people need to use version-specific requirements?)

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker