On Sat, 7 Jul 2018 at 03:42 Paul Moore <p.f.mo...@gmail.com> wrote: > On 30 June 2018 at 06:33, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 28 June 2018 at 11:37, Nathaniel Smith <n...@pobox.com> wrote: > >> So my inclination is to plan on ending up with build-system.requires > >> defaulting to ["setuptools", "wheel"], and build-system.backend > >> defaulting to "setuptools". Hopefully we'll eventually get to a place > >> where ~no-one uses these defaults, but carrying around the code to > >> handle the defaults isn't really a burden. > > > > While I was going to post to say I liked this approach, after a bit of > > reflection, I realised I prefer Thomas Kluyver's suggestion: instead > > of taking "pyproject.toml" as indicating a build-isolation compatible > > sdist file, instead make "pyproject.toml with a build-system table" > > the marker for that case. > > As far as I can see, the only difference this makes is that it means > pip retains the legacy (non-isolated) behaviour in a few more places > (specifically places where it's quite likley the project hasn't > thought about build isolation). So it's basically a slightly more > forgiving version of Nathaniel's proposal. > > The part of Nathaniel's approach that I think would be most confusing > is a project that currently uses setup_requires which adds a > pyproject.toml for (say) towncrier. The build would become isolated, > but setup_requires (which is implemented by setuptools, not pip) would > ignore the isolated environment and install in the wrong place (maybe? > I honestly don't know). I'm quite happy to call this deprecated > behaviour and point out that the project should switch to explicitly > using PEP 518, but given that this whole discussion is because people > haven't done that, I suspect Nathaniel's proposal doesn't actually > solve the root issue here... > > > If you don't have a build-system table at all, then you'll continue to > > get the legacy sdist handling, allowing the addition of other tool > > config without impacting the way your sdist gets built. > > > > If you do add a build-system table, then you have to populates the > > "requires" field properly, even if you're using setuptools as your > > build backend. > > > > That way, the "build-system.backend defaults to setuptools" behaviour > > is only there to support pyproject.toml files that have already opted > > in to build isolation by writing: > > > > [build-system] > > requires = ["setuptools", "wheel"] > > > > That sounds fair to me. In terms of PEP wording: > > 1. build-system.requires becomes *optional* in pyproject.toml > 2. Tools should process projects without pyproject.toml in the same > way as they always have (backward compatibility). For pip, that means > no build isolation, and the old-style processing path. > 3. Tools should treat projects with pyproject.toml, but with *no* > build-system.requires key the same way as (2). > 4. Tools can assume that no legacy behaviour is needed for projects > that specify pyproject.toml and build-system.requires. > > Moving forward to PEP 517, we'd allow a default for > build-system.backend purely as a convenience because PEP 518 was > implemented before PEP 517 - but there's no intention or commitment to > retain *current* PEP 518 code paths once PEP 517 is implemented (i.e, > nobody's suggesting that `build-system.backend missing` should *ever* > be different from `build-system.backend = "setuptools"`). > > Any objections?
I do have a question about whether we specifically want the existence of build-system.requires or the existence of the entire build-system section to trigger the fallback behaviour? Is there a situation where any PEP-defined key in that section makes sense without 'requires'? IOW should having a build-system section imply the requirement of build-system.requires and leaving that key out is an error, while leaving the entire section out is now optional and is what triggers the fallback behaviour? I personally vote to say that if you define build-system you should go all-in and those it's an error to be missing 'requires' in that case. > Specifically Brett made the point that this means that > as a community we're OK with pyproject.toml being the standard > location for tool configuration, and not just for specifying build > tools. I guess I'm personally OK with this (although I do feel that > it's something we didn't fully talk through when writing the PEP, and > we're now getting pushed down this route by circumstance). It might > warrant a change to the PEP title, just to clarify the modified > intent. > Yep, the PEP would need a quick once-over to make sure the wording makes sense if this is the final decision, new packaging BDFL. ;) > > Nathaniel - are you happy with this variant rather than the one you > proposed? > > Is someone going to prepare PRs for the PEP and for pip to match this > behaviour? I can handle any PEP updates once we have settled and the exact change we want. > It sounds important enough that it should probably go into > pip 18.0 (although that's a discussion we can have on the pip tracker > - I'm not sure there's much we need to do, and there may be a PR > already). > > Paul > > PS For completeness, here's the range of options. Shout if I > misrepresented anything. > > pyproject.toml build-system.requires Behaviour > -------------- --------------------- ----------------------------- > Does not exist N/A Legacy > Exists Does not exist Current: Invalid file (error) > Thomas: Legacy > Nathaniel: Isolated > (setuptools, wheel) > Exists Exists Isolated (full PEP 518) > So I think my suggestion changes this only such that build-system.requires becomes build-system, in which case it's a Thomas/Nathaniel debate, and then having build-system leading to the current behaviour.
-- 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/D2TCHUUJW4ZNQZ4Z5THEW3C46I2SJXDF/
