[Distutils] PEP for specifying build dependencies

[Nick Coghlan]

On 12 May 2016 at 19:07, Nathaniel Smith <njs at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia