On Mon, 16 Jul 2018 at 10:47 Pradyun Gedam <pradyu...@gmail.com> wrote:
> > > On Mon, 16 Jul 2018, 21:11 Paul Moore, <p.f.mo...@gmail.com> wrote: > >> 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" :-) >> > > I just perceive this as a case of - there's a nicer and arguably, cleaner > option and there's not much cost to getting there. Let's do that. :) > > I don't mind the status quo though. > > >> > 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. >> > > I'm referring to familiarity with the build-system table (through > build-system.requires being mandatory). If you have to add that table/key > when using those tools, people who work on those projects get to know about > the table. > > >> > 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. >> > > Not really. With mandatory, you can use --no-isolation - it would still > work fine for basically every user that has setuptools and wheel installed > in their current environment (that's almost every environment I'd say). > > >> If I've got that right, the costs for making the key mandatory are a >> lot higher. > > > My intuition/feeling here is that this cost is worth the network effects > that would make more users familiar with them. > I don't think all the pieces are quite there yet. E.g. there is no `pip sdist` to go with `pip wheel`, so we still have some work to do before we can really push people to entirely drop the old way of do things with minimal penalty. -Brett > > Pradyun > > 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/S5IMBAWPXQ2LS74QIW7CPGJRJO6ZWWDD/
