On Tue, 17 Jul 2018, 09:11 Brett Cannon, <br...@python.org> wrote: > 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. >
Ah. I now understand what you meant. I don't think the transition costs are very high here (more on this below). I also think most projects who've adopted pyproject.toml won't mind adding 2 lines to it, given enough time. (pip-specific deprecation details follow; I'm not sure how to explain the transition related costs in any other way) Since this would be a behavior change in pip, this would have to go through the standard deprecation cycle which would probably be about as long as the feature has been available currently. This means projects would have time to make releases with the key, that's similar to the amount of time the feature has been available as a part of pip. A functional difference here is that older releases with such pyproject.toml files would need an escape hatch after the change is made, to be installable. I don't think this is a major issue since when we'd flip the switch to start refusing, we'd start suggesting users to use the escape hatch or upgrade to a newer version, since the deprecation would make projects add the key and make newer releases. And, --no-isolation can serve as the escape hatch too. Pradyun > 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/OZWCXFNZZ7L7RLM3FWGAJQYNMZHQOKH2/
