On 19 July 2018 at 07:44, Pradyun Gedam <pradyu...@gmail.com> wrote: > > > On Tue, 17 Jul 2018, 20:44 Donald Stufft, <don...@stufft.io> wrote: >> >> >> On Jul 17, 2018, at 5:27 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> 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). >> >> >> I think that this is the most important reason not to go too crazy here. >> We >> should think of breaking changes as having a limited budget for >> introducing >> breaking changes, and the question then becomes where do we want to spend >> our >> budget? While something being relatively new means that the cost to our >> budget >> is smaller, it still has a cost and I just don’t think this is a great >> place to >> spend our budget at. >> >> On top of that, I don’t think the end result is significantly or >> meaningfully >> better for the end users, particularly if we ever get to a world where we >> isolate everything by default (which would mean that we would have to have >> an >> implicit requires of setuptools/wheel anyways). > > > Fair enough. I just wanted to > make the build-system table to be more visible to end > users, since I feel the cost here is justified by the benefit > s > . If others don't agree, > that's cool. I don't feel super strongly about this tbh > . I am not opposed to keeping > the status quo on this matter and am on board with Paul's suggestion of > making the > build-system table optional. :)
OK, thanks for confirming that. I think everyone who made comments on my proposal was ultimately saying something along the lines of "but I'm not sufficiently bothered to make a fight over it". So in the interests of bringing this discussion to a conclusion and moving on, I'm going to say that we go with what I proposed: 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, they should raise an error. 2. If [build-system] is missing, they should 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 there is any practical difference between cases 2a and 2b is tool-dependent. (It's not ideal that we don't make a recommendation between 2a and 2b, but getting into the details of pip's isolation strategy hasn't really helped make the choice more obvious, and I doubt that any new tools without pip's backward compatibility requirements would behave differently in the two cases anyway). Brett - you offered to update the PEP, so I'll leave that step to you. Thanks to everyone for the helpful discussions and willingness to compromise on the final outcome :-) 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/XLQILTH4E3JF52EZWJYVO63CLQEE5PVZ/
