My point is I don't think enough pieces are in place to force everyone over to --no-isolation to get by if they don't set up pyproject.toml as you're suggesting they be required to. IOW I think you're advocating something that's going to alienate people by pushing too hard.
On Mon, Jul 16, 2018, 19:30 Pradyun Gedam, <pradyu...@gmail.com> wrote: > > > 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/RYKCYQHA4CZXJKIEUEPPU3D3CTXQSWY3/
