On Sat, 23 Jun 2018, 03:08 Brett Cannon, <br...@python.org> wrote: > > > On Fri, 22 Jun 2018 at 10:19 Pradyun Gedam <pradyu...@gmail.com> wrote: > >> >> >> On Fri, 22 Jun 2018, 22:31 Brett Cannon, <br...@python.org> wrote: >> >>> >>> >>> On Fri, 22 Jun 2018 at 09:35 Pradyun Gedam <pradyu...@gmail.com> wrote: >>> >>>> Hey everyone! >>>> >>>> In PEP 518, it is not clearly specified how a project that has a >>>> pyproject.toml >>>> file but has no build-system.requires should be treated (i.e. >>>> build-system >>>> table). >>>> >>>> In pip 10, such a pyproject.toml file was allowed and built with >>>> setuptools >>>> and wheel, which has resulted in a lot of projects making releases that >>>> assumed >>>> that such a pyproject.toml file is valid and they use setuptools and >>>> wheel. >>>> I understand that at least pytest, towncrier and Twisted might have >>>> done so. >>>> This happened since these projects have included configuration for >>>> some tool in >>>> pyproject.toml (some of which use only pyproject.toml for >>>> configuration -- >>>> black, towncrier). >>>> >>>> There's a little bit of subtlety here, in pip 10's implementation: >>>> adding a >>>> pyproject.toml file enables a new code path that does the build in >>>> isolation >>>> (in preparation for PEP 517; it's a good idea on it's own too) with >>>> only the >>>> build-system.requires packages available. When the >>>> build-system.requires key >>>> is missing, pip falls back to assuming it should be ["setuptools", >>>> "wheel"]. >>>> The in-development version of pip currently prints warnings when the >>>> key is >>>> not specified -- along the lines of "build-system.requires is >>>> missing" + >>>> "A future version of pip will reject pyproject.toml files that do not >>>> comply >>>> with PEP 518." and falls back to legacy behavior. >>>> >>>> Basically, pip 10 has a distinction between a missing pyproject.toml and >>>> build-system.requires = ["setuptools", "wheel"] and the PEP doesn't. >>>> However, >>>> the PEP's precise wording here would help inform the debate about how >>>> pip >>>> should behave in this edge case. >>>> >>> >>> I think the precise wording is there by not having any wording. ;) If >>> 'requires' was meant to be optional then the PEP would have said that. >>> >> >> The PEP does say that the requires key is mandatory. Someone pointed out >> on the pip's tracker that it doesn't say that the build-system table is >> mandatory (or otherwise). >> > > It says "There will be a [build-system] table in the configuration file > to store build-related data". The word "will" does not suggest optional to > me. ;) Once again, no one said "optional", so assume it's required. >
Sounds good to me. > > >> And it seems that the JSON schema in the spec allows the table to be >> skipped entirely. That's part of the reason for this thread. >> > > The JSON schema is for "illustrative purposes only", so it should not be > viewed as part of the spec. > Yeah, that's exactly what I pointed out to the user in the pip issue tracker as well. > IOW if you need some authoritative judgement on this you have it from one > of the co-authors of the PEP. :) > Yeah. I think it's clear now what we have planned for pip is the right thing to do here. Thanks! Pradyun > -Brett > > >> >> >>> >>>> >>>> I can think of at least 2 options for behavior when >>>> build-system.requires is >>>> missing: >>>> >>>> 1. Consider a missing build-system.requires equivalent to either a >>>> missing >>>> pyproject.toml or build-system.requires = ["setuptools", "wheel"]. >>>> >>>> 2. Making the build-system table mandatory in pyproject.toml. >>>> >>>> I personally think (2) would be fine -- "Explicit is better than >>>> implicit." >>>> >>> >>> And I think that's what pip's warning is saying the future will be, but >>> they aren't quite yet ready to be that strict yet with their users (which I >>> can understand). >>> >>> >>>> >>>> It'll be easy to detect and error out in this case, in a way that it's >>>> possible >>>> to provide meaningful information to the user about what to do here. >>>> However, >>>> this does mean that some existing releases of projects become >>>> not-installable, >>>> which is concerning; I do think the benefits outweigh the costs though. >>>> >>>> Thoughts on this? >>>> >>> >>> I think what pip has planned with the warning makes sense. >>> >>
-- 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/ZN6MWEJPYAYV37XVDYGWHRWP4MGYGKBT/
