On Mon, Oct 12, 2009 at 11:34 AM, Tarek Ziadé <ziade.ta...@gmail.com> wrote: > On Mon, Oct 12, 2009 at 6:10 PM, Ian Bicking <i...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig