On Sat, 7 Jul 2018, 16:12 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? 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. > > 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? 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). > I'll be happy to update pip for this after the PEP update. It's probably gonna be updating a conditional or so. :) > 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) > The pip 10 behavior is not erroring out. That's why we're having this discussion. ;) It's wrapped with an unexpected change in behavior for users (isolation and everything that brings) - it's basically what Nathaniel suggested. Erroring out is what I'd proposed initially in this thread, maybe that caused this confusion. I still prefer erroring out and providing transitory escape hatches, so I'll make another push for in a follow up mail (going into a flight). Pradyun -- > 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/5DIB5C6KTBGRMLJ5H23UEJSZW5TVE2EA/
-- 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/UOQEZJVRIXCY27PG3D3R4DVDNDNWC4OW/
