On 16 July 2018 at 15:56, Pradyun Gedam <pradyu...@gmail.com> wrote: > > On Mon, 16 Jul 2018, 20:16 Brett Cannon, <br...@python.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, <p.f.mo...@gmail.com> wrote: >>> >>> The discussion on this appears to have died down. >>> >>> As far as I can tell, the consensus is essentially: >>> >>> 1. 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: >>> >>> 1. If [build-system] is present but requires is missing, raise an error. >>> 2. 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. Paul -- 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/73VDP2Y455ICOJTEJ5OZZMD4Z6K3QTZ5/
