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.
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. 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). Pradyun >> Paul >> >> PS Following on from >> >> >> I think it would be helpful for this discussion if we could look at >> these >> >> bug reports – do does anyone have links? >> > >> > Good point. I will hunt them out and post here. >> >> I mentioned this on the pip issue, but the only pip problem which has >> been raised with the current behaviour is around cases where the user >> disabled PyPI access and doesn't have a local copy of >> setuptools/wheel, which means we can't build the isolated environment. >> But that's a corner case that is easily resolvable, and I don't think >> it needs to affect pip's choice of behaviour (much less what the PEP >> says). >> >> >> On 10 July 2018 at 08:03, Paul Moore <p.f.mo...@gmail.com> wrote: >> > On 10 July 2018 at 05:09, Pradyun Gedam <pradyu...@gmail.com> wrote: >> >> On Tue, Jul 10, 2018 at 2:30 AM Paul Moore <p.f.mo...@gmail.com> >> wrote: >> >>> For now I'll point out that PEP 518 doesn't say *anything* about how >> >>> tools use the information in `pyproject.toml` - there's no mention of >> >>> build isolation. Unless I missed something - please point it out if I >> >>> did, The only thing I can find is in PEP 517. So discussions of pip's >> >>> isolation behaviour are mostly pip-specific implementation details at >> >>> the moment, and not really relevant to this thread. >> >> >> >> Ah, okay. So, isolation is purely an implementation issue, so it >> doesn't >> >> need to come around in this discussion which is about how we should >> >> change the PEP. I guess I'm still figuring out where to draw the line >> >> between implementation details and the PEP details here since they >> >> should/would influence each other both ways. I'll try to be more >> careful >> >> about stuff like this in the future. :) >> > >> > Not a problem. Isolation is discussed in PEP 517, which is why I was >> > getting confused about what was related to the standard and what to >> > the implementation. We will need to be careful to review all this once >> > we start implementing PEP 517, but for now at least that's a level of >> > complexity we don't need in this discussion. >> > >> > 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/BERTMHYYQVYW36PKSER5H3TBUDSNMESW/
