On Sat, Jul 7, 2018 at 3:41 AM, 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...
Re: the interaction of build isolation and setup_requires: it looks like this is totally fine, actually. Based on some experiments + checking the docs, it appears that setup_requires has always done some magic where it doesn't actually try to install the requested packages into the current environment, but instead drops them inside the build directory and then uses some import system tricks to "overlay" them onto the current process's python path. So build isolation + setup_requires actually work very well together. I think in the long run, we want to enable build isolation everywhere. Packages that break when installed with build isolation are already broken when running 'pip install' in a fresh virtualenv. There probably are a few of these out there still that say things like "before installing this package, please install these other packages, as a separate call to pip", but it's been a long time now since I've seen one of those. And since they're already asking users to follow some finicky manual install procedure, requiring --no-build-isolation isn't a big deal. So, I don't care that much about what we use to trigger build isolation mode, because it's only a temporary thing anyway. The value of keying off something involving pyproject.toml is that it automatically gives us a kind of soft rollout: people adopting pyproject.toml are probably more willing to put up with issues with new packaging features, so we can hopefully shake out any problems before it becomes the standard. This suggests that our decision should be based on: if we want to be relatively more aggressive about rolling out build isolation, then we should key on the existence of pyproject.toml. If we want to be relatively more conservative, then we should key on the existence of build-system.requires. >> 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"`). I think that once we make build isolation the default, this proposal and my proposal will become equivalent: To use build-isolation when there's no pyproject.toml, or no build-system.requires, then obviously we'll need to default to installing ["setuptools", "wheel"] into the isolated environment. And then we'll need to run 'setup.py', like with the legacy system... which is exactly what the setuptools build-backend will do. So there won't be any reason for pip to keep carrying around its own copy of the setup.py invocation code; it can handle legacy packages through build-system.backend = "setuptools". In fact I guess that's what you just said at the end of the quoted paragraph. So basically the end state is the same either way: if build-system.requires is missing, we default to ["setuptools", "wheel"], and if build-system.backend is missing, we default to "setuptools", and that's it, no complicated legacy code-paths inside pip. So, it probably doesn't matter too much which we choose. [Hmm, I just noticed that we're both using "build-system.backend" as the name of the key, but PEP 517 actually uses "build-system.build-backend". The PEP's name is a bit redundant, isn't it.] > 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. I'm fine with pyproject.toml becoming more central. If anything I think we might want to take this further. Maybe I'll start a thread about that :-). > Nathaniel - are you happy with this variant rather than the one you proposed? If we're agreed that we will eventually make build-isolation the default, then I think either plan is fine. I guess I still like my proposal *slightly* better, because it seems a bit simpler to explain, and it gets us more testing of build-isolation mode, sooner. But I'm not going to make a fuss about it. If there's some reason we *don't* plan to eventually make build-isolation mode the default, and will need to keep legacy code paths inside pip indefinitely, then that makes this much more complicated and I'd want to think it through more carefully. Hopefully no-one sees any terrible flaws with making build-isolation the default (eventually)? -n -- Nathaniel J. Smith -- https://vorpus.org -- 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/U4MXN2W7KJNJ343SRVQDNRFSCNVK4BQK/
