On 12 May 2016 at 19:07, Nathaniel Smith <n...@pobox.com> wrote: > When we were spitballing the draft, I think where [package] originally > came from was the idea that having semantics-version at the top level > is not actually useful -- most tools will only care about the > semantics of the [tool.whatever] table and the only PEP change that > would affect them is if we for some reason redefined the [tool] table > itself. Which we aren't going to do. But if semantics-version is > top-level, then presumably everyone has to check for it and error out > if it changes. So bumping semantics-version would cause all these > tools to error out, even though the part of the file that they > actually care about didn't change, which would mean in practice we > would just never actually bump the semantics-version because the flag > day would be too painful. Introducing a [package] level and pushing > semantics-version down inside [package] insulates from that. > > ...Given how complicated this is ending up being, I'm sorta inclined > to just drop semantics-version. It's only in there as a "hey why not > it doesn't hurt" thing. I can't imagine any situation in which we'd > actually bump the semantics version. If we need to make some > incompatible change we'll actually do it by adding a [build-system-2] > or something, and specify that [build-system] and [build-system-2] are > both allowed in the same file, and if both are present then new tools > should ignore [build-system] -- way smoother and backwards-compatible.
We could also keep semantics-version, and just put it inside [build-system]. Either way, by allowing access to the [tool.*] namespace without any other version check, the key constraint we're placing on ourselves is a commitment to only making backwards compatible changes at the top level of the schema definition, and that should be a feasible promise to keep. While I can't conceive of an eventuality where we'd need to break such a promise, even if we did, the change could be indicated by switching to a different filename. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
