(I thought I'd sent this but it was in my drafts instead) 

On Sun, Jul 8, 2018 at 9:14 AM Nathaniel Smith <njs@pobox.com> wrote:
> On Sat, Jul 7, 2018 at 3:41 AM, Paul Moore <p.f.moore@gmail.com> wrote:
> > On 30 June 2018 at 06:33, Nick Coghlan <ncoghlan@gmail.com> wrote:
> >> On 28 June 2018 at 11:37, Nathaniel Smith <njs@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.

Indeed. I too feel that's what this comes down to. I had a wordier way to come to this conclusion which I've removed from this mail now. :)

An important thing here is that being aggressive here let's us piggy-back on the adoption of tools that use pyproject.toml and I'd say it's a good thing to have more people using the standard explicitly.

Having to specify the build-system.requires in pyproject.toml isn't going to be a problem for most (almost all?) packages. The status quo is that *they are using isolation* if there's a pyproject.toml. It won't break/change anything if they do specify the key in a future release within the pyproject.toml that's already there. In fact, requiring packages specify this information would serve to make people more familiar with it.

FWIW, if build isolation is causing issues for a package, they'll have the same UX as today (passing --no-build-isolation) if we go ahead with compulsory requires.

As for the existing released packages with missing requires, we'll have an escape hatch (the same --no-build-isolation or something more targeted if we want that'd be an implementation thing) that'll work just fine for such packages too; a transitory warning followed by an error message seems like a smooth enough transition to me.

pip 10's PEP 518 implementation was clearly documented to be incomplete so IMO making changes isn't really a huge problem here, especially given that there's a clean-ish transition path available for nearly every use case involved (users, packagers and the entire grid of legacy/missing/specified).

I feel that if a project has been quick to adopt a new standard that's documented as implemented incompletely currently, it seems reasonable to make a 2 line change to comply with the standard as it matures. The fact that the project did it for a tool doesn't exempt them from this IMO.

Basically, my position is that being more aggressive is a better way to go about this than being conservative - having to a way to use the legacy behavior for users that are benefiting from our newly specified standard, whose intended use was/is to move them away from the legacy behavior, just feels weird to me.

Pradyun (on mobile)

> >> 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-leave@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/