On Wed, May 11, 2016 at 7:22 PM, Donald Stufft <don...@stufft.io> wrote: [...] > Now, you could argue that the [package] keyword is superfluous and in > reality it’s highly unlikely that we ever get anything major that would ever > sit as a sibling to it (besides tool) and thus it doesn’t make sense to pay > the cost of those extra 8 characters when it is probably going to be the > only non-tool value ever. Personally I think hedging our bets and leaving > the door open for that possibility is a nice thing to do when the cost is so > low. However, I don’t think it’d be unreasonable or silly to make the other > trade off and just say that having it isn’t valuable and just stick > [build-system] at the top level along with [tool.*] and say that if we ever > come up with something that is not related to a package (in the PyPA sense) > that it really won’t be that big of a deal to just have it live beside stuff > like [build-system]. > > So I think we should either have: > > [package.build-system] > requires = [“setuptools”, “wheel”] > > [tool.flake8] > … > > OR > > [build-system] > requires = [“setuptools”, “wheel”] > > [tool.flake8] > … > > but I don’t think trying to make the parsed tree fit some “correct” > hierarchy of data types when you consider the [tool] section (which really > only exists to prevent collisions, otherwise we’d just let people stick > [flake8] etc at the top level) is worth it.
FTR, to the extent that I object to [package] it's nothing to do with character count and purity, and instead to do with it being a bit confusing / poor UI, because as we've seen no-one's really sure what a "package" is. It's not a huge deal, but it might create some user confusion and future-PEP-author confusion. My preference ordering: [common.build-system] = [build-system] > [package.build-system] > nothing -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig