[Distutils] PEP for specifying build dependencies

[Brett Cannon]

On Thu, 12 May 2016 at 05:43 Donald Stufft <donald at stufft.io> wrote:

>
> > On May 12, 2016, at 8:31 AM, Nick Coghlan <ncoghlan at 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160512/127016e8/attachment.html>