[Distutils] comparison of configuration languages

Nick Coghlan ncoghlan at gmail.com
Sun May 8 09:13:24 EDT 2016

On 8 May 2016 at 08:46, Donald Stufft <donald at stufft.io> wrote:
>> On May 7, 2016, at 5:05 PM, Robert Collins <robertc at robertcollins.net> wrote:
>> Either we are defining the long term thing now, in which case that
>> huge pile of complexity lands on us, and we have to get everything
>> right.
>> Or we are defining a thing which solves the present bug, and as long
>> as we make sure it does not bind us in future, we're not hamstrung.
>> E.g. use setup.cfg now. Add pybuild.toml later. (btw, terrible name,
>> as pybuild is a thing in the debian space, and this will confuse the
>> heck out of folk). https://wiki.debian.org/Python/Pybuild
> I think this is roughly true, we could either do the simplest thing and just
> add ``setup_requires`` to ``setup.cfg`` and teach pip how to understand them
> and then worry about a new format later, or we can do a new format now and add
> a bit of complexity to what we need to specify (though I don't think _too_ much
> complexity, we don't have to define the build system stuff now, just make sure
> we don't back ourselves into a corner with that).
> I think either answer is OK, just the second one is a bit more work and we
> might either get the start of a better format _now_ or end up regretting what
> we pick when we add more things to it.

Hmm, are we perhaps forcing a false choice on ourselves here?

1. setup_requires in setup.py is the de facto baseline

2. d2to1 and pbr already use setup.cfg, so any arguments about the
readability of the format are moot for users of those projects

3. we're not sure we're comfortable mandating the use of an ini-style
format for all *future* Python projects

So let's reduce our scope to: "We want *current users* of d2to1 and
pbr to be able to declare those dependencies to pip and other
installation tools in a way that avoids the implicit invocation of
easy_install by setuptools"

For *that* design goal, the conclusions I'd draw from Nathaniel's
write-up would be those Łukasz suggested:

- use https://pypi.python.org/pypi/configparser in Python 2.7
- explicitly define how to handle end-of-line comments

We should perhaps also recommend that "#" be used for comments (even
if the parser didn't enforce that), as I haven't seen anyone using ';'
for comments since I stopped writing assembly code by hand.

Improving the status quo for d2to1 and pbr users doesn't lock us into
anything in terms of the "future of Python packaging as a whole".
Individual build system authors may *choose* to take advantage of the
setup.cfg mechanism, but they wouldn't be obliged to - they could keep
using setup.py based bootstrapping if they preferred to do so.

This approach would also provide the ability to iterate on a TOML
based dependency declaration system *independent of pip itself*:
setup.cfg could be used to bootstrap that system while it was still
experimental, letting the idiosyncrasies get worked out before we
commit to anything in pip itself.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list