On Thu, 12 May 2016 at 05:43 Donald Stufft <don...@stufft.io> wrote: > > > On May 12, 2016, at 8:31 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > > 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. > > I don't think we should put it inside of [build-system], largely because I > think the chances we ever need to increment the version is very small, and > I > feel like putting it inside of [build-system] means we'll then need one for > any other top level key we put in. Each additional one is additional > complexity > and increases the chance that some tool doesn't accurately check every > single > one of them. Putting it inside of [package] made some sense, because that > was > going to be a container for all of the things that one particular group of > people (distutils-sig / PyPA) "managed" or cared about but I think that > putting > it on each individual sub section is just overkill. >
Everything that Nathaniel and Donald said is accurate about the discussion we had offline while drafting the PEP. Top-of-file was originally proposed by me but was viewed as too broad, hence the namespacing of the bits PyPA controlled and putting the field in there. We also considered per-table, but that seemed like overkill. > > We can easily stick it at the top level of the file and just explicitly > state > that the [tool.*] namespace is exempt from deriving any sort of meaning > from > the semantics-version value. I think that is easier to not screw up (only > one > check, vs N checks) and I think that it looks nicer too from a human > writing/editing POV if we ever do bump the version and force people to > write it > out: > I had originally proposed that but I think we didn't like the wording of it or the possibility of someone not realizing that the scoping of the field was special-cased to everything *not* in [tool]. > > semantics-version = 2 > > [build-system] > requires = [ > "setuptools", > "pip", > ] > > [test-runner] # Just an example > command = "py.test --strict" > requires = [ > "pytest", > ] > > [tool.pip] > index-url = "https://index.example.com/simple/"; > > But honestly, I'm of the opinion we could probably just ditch it. I don't > think > it'll be hard to maintain compatibility within the keywords we pick in this > file and I worry that by including it in something that we expect humans to > write, we provide an incentive to using it when perhaps we could think up a > better, backwards compatible syntax. The main argument in favor of adding > it > now with an implicit default of `1` is that if I'm wrong and we end up > needing > it, including it now will mean that projects are actively checking the > version > number so we can safely increase it with the desired effect. If we don't > include it now, then even if we add it at a later date nothing will be > checking > to see if that changed or not. > Both Donald and Nathaniel say to drop it, and since I put it in just to be overly cautious I'm fine with dropping it. So unless Nick says "semantics-version or death!", I agree w/ my co-authors and would update the PEP to say: 1. no semantics-version 2. [build-system] instead of [package.build-system]
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
