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.
> >> 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
> 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
> 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
> > 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
> Nathaniel J. Smith -- https://vorpus.org
> Distutils-SIG mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to email@example.com
> Message archived at https://firstname.lastname@example.org/message/U4MXN2W7KJNJ343SRVQDNRFSCNVK4BQK/