On 8 May 2016 at 08:46, Donald Stufft <don...@stufft.io> wrote: > >> On May 7, 2016, at 5:05 PM, Robert Collins <robe...@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. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
