On 19 July 2018 at 07:44, Pradyun Gedam firstname.lastname@example.org wrote:
On Tue, 17 Jul 2018, 20:44 Donald Stufft, email@example.com wrote:
On Jul 17, 2018, at 5:27 AM, Paul Moore firstname.lastname@example.org 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