<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 12 May 2016 at 05:43 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 12, 2016, at 8:31 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> We could also keep semantics-version, and just put it inside [build-system].<br>
><br>
> Either way, by allowing access to the [tool.*] namespace without any<br>
> other version check, the key constraint we're placing on ourselves is<br>
> a commitment to only making backwards compatible changes at the top<br>
> level of the schema definition, and that should be a feasible promise<br>
> to keep. While I can't conceive of an eventuality where we'd need to<br>
> break such a promise, even if we did, the change could be indicated by<br>
> switching to a different filename.<br>
<br>
I don't think we should put it inside of [build-system], largely because I<br>
think the chances we ever need to increment the version is very small, and I<br>
feel like putting it inside of [build-system] means we'll then need one for<br>
any other top level key we put in. Each additional one is additional complexity<br>
and increases the chance that some tool doesn't accurately check every single<br>
one of them. Putting it inside of [package] made some sense, because that was<br>
going to be a container for all of the things that one particular group of<br>
people (distutils-sig / PyPA) "managed" or cared about but I think that putting<br>
it on each individual sub section is just overkill.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We can easily stick it at the top level of the file and just explicitly state<br>
that the [tool.*] namespace is exempt from deriving any sort of meaning from<br>
the semantics-version value. I think that is easier to not screw up (only one<br>
check, vs N checks) and I think that it looks nicer too from a human<br>
writing/editing POV if we ever do bump the version and force people to write it<br>
out:<br></blockquote><div><br></div><div>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].</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    semantics-version = 2<br>
<br>
    [build-system]<br>
    requires = [<br>
        "setuptools",<br>
        "pip",<br>
    ]<br>
<br>
    [test-runner]  # Just an example<br>
    command = "py.test --strict"<br>
    requires = [<br>
        "pytest",<br>
    ]<br>
<br>
    [tool.pip]<br>
    index-url = "<a href="https://index.example.com/simple/" rel="noreferrer" target="_blank">https://index.example.com/simple/</a>"<br>
<br>
But honestly, I'm of the opinion we could probably just ditch it. I don't think<br>
it'll be hard to maintain compatibility within the keywords we pick in this<br>
file and I worry that by including it in something that we expect humans to<br>
write, we provide an incentive to using it when perhaps we could think up a<br>
better, backwards compatible syntax. The main argument in favor of adding it<br>
now with an implicit default of `1` is that if I'm wrong and we end up needing<br>
it, including it now will mean that projects are actively checking the version<br>
number so we can safely increase it with the desired effect. If we don't<br>
include it now, then even if we add it at a later date nothing will be checking<br>
to see if that changed or not.<br></blockquote><div><br></div><div>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:</div><div><ol><li>no semantics-version</li><li>[build-system] instead of [package.build-system]</li></ol><div><br></div></div></div></div>