On 16 July 2018 at 15:56, Pradyun Gedam email@example.com wrote:
On Mon, 16 Jul 2018, 20:16 Brett Cannon, firstname.lastname@example.org wrote:
I will update the PEP and add you as a reviewer, Paul (might not get to it until Friday, though).
On Mon, Jul 16, 2018, 02:23 Paul Moore, email@example.com wrote:
The discussion on this appears to have died down.
As far as I can tell, the consensus is essentially:
- It should be legal for pyproject.toml to *not* contain a
[build-system] section. 2. If a [build-system] section is present, the requires key must be present.
Tools should behave as follows:
- If [build-system] is present but requires is missing, raise an error.
- If [build-system] is missing, they can take one of the following
two approaches: a) Act as if pyproject.toml is missing altogether b) Act as if [build-system] is present, with a requires value of ["setuptools", "wheel"]
Whether tools act differently in cases 2a and 2b is tool-dependent (for pip, we would isolate in case 2b but not in case 2a) which is why the choice is left to individual tools. That makes the "Thomas/Nathaniel" debate into a tool implementation choice, and both of the options are allowable from the perspective of the PEP.
Is everyone OK with this resolution? If so, will someone raise a PR for PEP 518? I can do that if no-one else can.
While I don't mind if we'd go ahead with this (and 2b, to not change existing behavior), I still think making the key mandatory would be a good/better idea.
I get the feeling that no-one is sufficiently motivated to argue strongly for any particular resolution - which is why my summary is basically "accept the current behaviour as correct" :-)
The visibility (and hence familiarity) that this would gain from the specification of build-system.requires being mandatory would be nice to have. I feel that this would otherwise be a missed opportunity to push for the key and standard to be more visible to users and packagers.
But adoption of pyproject.toml as a standard configuration file by projects like towncrier and black is doing that already.
The transitory cost for existing packages that break due to this being mandatory would probably be fairly minor (I realize that this point is where I dwelled into implementation details earlier, so I'll not digress there now).
I believe the transition costs for projects (and their users) using pyproject.toml for config only are:
Optional, only isolate if [build-system] is present: None Optional, isolate if pyproject.toml is present: The few *end users* for whom isolation breaks the build have to pass --no-build-isolation Mandatory: The *project* has to add the [build-system] section, and make a new release. End users have to wait for that release.
If I've got that right, the costs for making the key mandatory are a lot higher. The costs for 2b are there, but a lot smaller (and the end user has a workaround). Option 2a has no costs, but also misses the opportunity to move towards build isolation by default for a few extra cases.