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.
On Fri, Jun 22, 2018 at 9:32 AM, Pradyun Gedam email@example.com wrote:
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:
Consider a missing build-system.requires equivalent to either a missing pyproject.toml or build-system.requires = ["setuptools", "wheel"].
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?
-- Distutils-SIG mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://firstname.lastname@example.org/message/7...