On 17 July 2018 at 08:45, Pradyun Gedam <pradyu...@gmail.com> wrote: > > 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.
OK. So if we ignore pip details for the moment (I'll come back to them later) then you want to argue that 1. Projects which have currently added a pyproject.toml file with tool config but no [build-system] section are wrong to do so. At best they've misinterpreted the current PEP wording, and we're going to issue a revised PEP wording that makes it clear that they are wrong. At worst they never read the new PEP, just heard about pyproject.toml from the towncrier/black docs (and those don't mention [build-system] - see https://github.com/hawkowl/towncrier/blob/master/README.rst for example). 2. Those projects need to modify pyproject.toml, and until they do they will be in violation of the PEP (at least of the revised PEP). 2a. Towncrier need to modify their docs to *not* recommend creating an invalid pyproject.toml. 3. The only indication they get that they are in violation will come from their users using pip 18.0 and later, who will report deprecation warnings (and later failures) to them. 4. The users can work around the issue by using --no-build-isolation, but a final solution has to come from the project. 5. The projects can relatively trivially fix the issue by adding a [build-system] section to pyproject.toml, but they will need to make a new release. The costs are fairly clear here - projects that are in this situation (and we don't know how many there are, but we know there are some from pip bug reports) will need to make a new release to conform to the (revised) PEP. The route for the project to find out that there is an issue is user gets a warning from pip -> user reports the issue (probably initially to pip, and we'll have to redirect them to the project) -> project fixes the issue. There's also a PR cost, in that projects who have enthusiastically adopted pyproject,toml as being a nice "common configuration" location, will be left feeling that maybe that wasn't such a good decision if it's causing them problems like this. Plus, projects like towncrier will need to update their docs (yes, that's a bit ideal world - the reality is that people simply keep doing what they do now, and we get the message out via a gradual process of addressing bug reports and providing the explanation there). The benefits are less obvious - a slightly simpler PEP, and what? It's not as if pip gets to test out its isolation code on any additional projects, as option 2b in my proposal does that anyway. It's not that pyproject.toml gets any more visibility - projects hitting this are already using it. > (pip-specific deprecation details follow; I'm not sure how to explain the > transition related costs in any other way) See above. The *costs* are simple - projects must change and release a new version, possibly some bad PR for the pyproject.toml format. The pip-specific side is about *benefits* - are there any that justify these costs? > 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. Agreed. So starting with pip 18.0, end users would see warnings "pyproject.toml has no [build-system] section, please correct that file". But the install would proceed. We'd have to hope that those users would take the time to report that warning (as in many cases they won't be the project owners). > 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. Surely not? The point of having a deprecation warning is precisely that, after we flip the switch, we *stop* allowing the old format? This sounds like the worst of both worlds. End users can always use --no-build-isolation (at least until we finally kill off the legacy code paths altogether). But that's not a fix for having an invalid pyproject.toml, that's opting out of all of the new processing/features completely. To be frank, I actually think that tools having picked up on pyproject.toml is a good thing, as it's added publicity for PEP 518. I think we should capitalise on that and make sure that we don't break projects that have taken this step. I don't have a problem with isolating in this case, as that seems to cause little problem (and where it does, the explanation isn't hard) and it makes sure we get real-world feedback on how projects that *haven't* bought into the full PEP 517/518 workflow will be impacted. 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/PV3CFTTZ6NKE76E2X2UBQR2SEFBJ4MSD/
