Sorry to bump into this so late, but:
Would not 2a be more backward compatible than 2b? I mean people may have build environments/installs doing: - pip install setuptools-scm setuptools pbr - pip install os-system-level
This way you can bypass the setup requires of setuptools to use easy_install. With 2b there is no way to avoid setup requires elements to not trigger easy install; other than os-system-level (which requires pbr for setup) to switch to pyproject.toml.
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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://email@example.com/message/X...