PEP 518 - pyproject.toml with no build-system.requires

Bernat Gabor <[email protected]>
Newsgroups gmane.comp.python.distutils.devel
Message-ID <CALBzji4gQoncnj0V=rt-HF--pHvqtFWpLevVSeyA6_aA9LNOvQ@mail.gmail.com>
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 valu
 e 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 i
 nto 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 protected] To unsubscribe send an email to [email protected] https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/XLQILTH4E3JF52EZWJYVO63CLQEE5PVZ/
--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/PTNKGMJ6VGMTUXUWDQKI56FGZJCBDW3O/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.