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
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 --
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
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?