On Tue, 17 Jul 2018, 00:45 Brett Cannon, <br...@python.org> wrote: > > > 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. >
I do agree that not having all pieces is a problem for users currently (early adopters) and we should try to get to the point where you can entirely drop the "old way" sooner than later. :) I feel like you're making a point here that I'm not able to understand what for. This is still going to hold true with status quo until we do that work so this doesn't count against mandatory requires per se. The additional visibility of this won't be a strong push IMO until this does become a feasible alternative. Pradyun > -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/CQ26PAVDDTYGB4YSEUWQRWHLW66BPBAR/
