On Mon, 16 Jul 2018, 21:11 Paul Moore, <p.f.mo...@gmail.com> wrote: > On 16 July 2018 at 15:56, Pradyun Gedam <pradyu...@gmail.com> wrote: > > > > On Mon, 16 Jul 2018, 20:16 Brett Cannon, <br...@python.org> wrote: > >> > >> I will update the PEP and add you as a reviewer, Paul (might not get to > it > >> until Friday, though). > >> > >> On Mon, Jul 16, 2018, 02:23 Paul Moore, <p.f.mo...@gmail.com> wrote: > >>> > >>> The discussion on this appears to have died down. > >>> > >>> As far as I can tell, the consensus is essentially: > >>> > >>> 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, raise an > error. > >>> 2. If [build-system] is missing, they can 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 tools act differently in cases 2a and 2b is tool-dependent > >>> (for pip, we would isolate in case 2b but not in case 2a) which is why > >>> the choice is left to individual tools. That makes the > >>> "Thomas/Nathaniel" debate into a tool implementation choice, and both > >>> of the options are allowable from the perspective of the PEP. > >>> > >>> Is everyone OK with this resolution? If so, will someone raise a PR > >>> for PEP 518? I can do that if no-one else can. > > > > While I don't mind if we'd go ahead with this (and 2b, to not change > > existing behavior), I still think making the key mandatory would be a > > good/better idea. > > I get the feeling that no-one is sufficiently motivated to argue > strongly for any particular resolution - which is why my summary is > basically "accept the current behaviour as correct" :-) >
I just perceive this as a case of - there's a nicer and arguably, cleaner option and there's not much cost to getting there. Let's do that. :) I don't mind the status quo though. > > The visibility (and hence familiarity) that this would gain from the > > specification of build-system.requires being mandatory would be nice to > > have. I feel that this would otherwise be a missed opportunity to push > for > > the key and standard to be more visible to users and packagers. > > But adoption of pyproject.toml as a standard configuration file by > projects like towncrier and black is doing that already. > I'm referring to familiarity with the build-system table (through build-system.requires being mandatory). If you have to add that table/key when using those tools, people who work on those projects get to know about the table. > > The transitory cost for existing packages that break due to this being > > mandatory would probably be fairly minor (I realize that this point is > where > > I dwelled into implementation details earlier, so I'll not digress there > > now). > > I believe the transition costs for projects (and their users) using > pyproject.toml for config only are: > > Optional, only isolate if [build-system] is present: None > Optional, isolate if pyproject.toml is present: The few *end users* > for whom isolation breaks the build have to pass --no-build-isolation > Mandatory: The *project* has to add the [build-system] section, and > make a new release. End users have to wait for that release. > Not really. With mandatory, you can use --no-isolation - it would still work fine for basically every user that has setuptools and wheel installed in their current environment (that's almost every environment I'd say). > If I've got that right, the costs for making the key mandatory are a > lot higher. My intuition/feeling here is that this cost is worth the network effects that would make more users familiar with them. Pradyun The costs for 2b are there, but a lot smaller (and the end > user has a workaround). Option 2a has no costs, but also misses the > opportunity to move towards build isolation by default for a few extra > cases. > > 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/YJ22D4JIGXLNFCZXCCT22NR67OBRW6F5/
