To go a bit against the grain here, I think at this point I'd suggest
that if "build-system.requires" is missing, it should be silently
treated as if it had been set to ["setuptools", "wheel"]. Reasoning:
- Implementing this should require only a trivial amount of code, now
and in the long run. In particular, I'm *not* suggesting that if the
"build-system.requires" key is missing then we should act like
pyproject.toml is missing altogether -- that's a much more complex
legacy code path that we'd like to eventually remove. I'm suggesting
we literally do something like:
try:
requires = config["build-system"]["requires"]
except KeyError:
requires = ["setuptools", "wheel"]
and then treat them exactly the same from then on.
- Not doing this breaks a number of real projects. Sometimes this is
justifiable because we have to break things to make progress, but it
always creates busywork and pisses people off, so we should only do it
when we have a good reason. In this case providing a default value is
pretty trivial, and will prevent a lot of frustrated queries about why
it's mandatory.
- Providing a default doesn't really compromise the final vision for
the feature: we envision that eventually, pretty much every project
will be specifying this explicitly, and won't *want* to leave it
blank. There isn't any other meaning we want to assign to this being
left blank.
- We're soon going to have to jump through all these hoops *anyway*
for the PEP 517 "build-system.build-backend" key. If it's missing,
then we're going to want to default it to "setuptools" (once
setuptools exports a PEP 517 build backend), which means we're going
to be hardcoding some defaults and knowledge of setuptools into the
pyproject.toml defaults. So we might as well do this for both keys in
the same way.
-n
On Fri, Jun 22, 2018 at 9:32 AM, Pradyun Gedam <pradyu...@gmail.com> wrote:
> Hey everyone!
>
> In PEP 518, it is not clearly specified how a project that has a
> pyproject.toml
> file but has no build-system.requires should be treated (i.e. build-system
> table).
>
> In pip 10, such a pyproject.toml file was allowed and built with setuptools
> and wheel, which has resulted in a lot of projects making releases that
> assumed
> that such a pyproject.toml file is valid and they use setuptools and wheel.
> I understand that at least pytest, towncrier and Twisted might have done so.
> This happened since these projects have included configuration for some tool
> in
> pyproject.toml (some of which use only pyproject.toml for configuration --
> black, towncrier).
>
> There's a little bit of subtlety here, in pip 10's implementation: adding a
> pyproject.toml file enables a new code path that does the build in isolation
> (in preparation for PEP 517; it's a good idea on it's own too) with only the
> build-system.requires packages available. When the build-system.requires key
> is missing, pip falls back to assuming it should be ["setuptools", "wheel"].
> The in-development version of pip currently prints warnings when the key is
> not specified -- along the lines of "build-system.requires is missing" +
> "A future version of pip will reject pyproject.toml files that do not comply
> with PEP 518." and falls back to legacy behavior.
>
> Basically, pip 10 has a distinction between a missing pyproject.toml and
> build-system.requires = ["setuptools", "wheel"] and the PEP doesn't.
> However,
> the PEP's precise wording here would help inform the debate about how pip
> should behave in this edge case.
>
> I can think of at least 2 options for behavior when build-system.requires is
> missing:
>
> 1. Consider a missing build-system.requires equivalent to either a missing
> pyproject.toml or build-system.requires = ["setuptools", "wheel"].
>
> 2. Making the build-system table mandatory in pyproject.toml.
>
> I personally think (2) would be fine -- "Explicit is better than implicit."
>
> It'll be easy to detect and error out in this case, in a way that it's
> possible
> to provide meaningful information to the user about what to do here.
> However,
> this does mean that some existing releases of projects become
> not-installable,
> which is concerning; I do think the benefits outweigh the costs though.
>
> Thoughts on this?
>
> Cheers,
> Pradyun
>
>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7A4QHWCHR54TSIO2DQZUVNZHZS6ZPBLY/
>
--
Nathaniel J. Smith -- https://vorpus.org
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/4QWJJAPLH7HECEMOPUFVFX35VVR5MJ4L/
