Default to isolated, pyproject.toml-based builds

[dstufft]

Update on Oct 7 2022: Once setup.py install and setup.py develop code paths are killed, there is no reason for pip to use the legacy setup.py-based builds by default, other than to avoid the additional overhead of the creation of build environments.

---

Currently if you try to pip install something that only is provided a "legacy" setuptools only sdist without a pyproject.toml, that will be installed using the "legacy" path unless you explicitly invoke --use-pep517.

This is particularly troublesome in cases where you don't have (or want to have) setuptools installed in the environment, since the legacy path depends on having setuptools preinstalled.

This flag does not affect editable installs in any way, and those still require having setuptools preinstalled in either case.

This seems like it would be a good stepping stone on the way to #6334, since it narrows the cases where we're using the legacy path to just editable installs.

[pfmoore]

This sounds like a good idea to me. I think PEP 517 has been around long enough to make this a reasonable change.

One thought I had was whether we needed a deprecation period here. But we're not actually deprecating anything, just changing the default, so I don't think we necessarily need one. It is an incompatible change, so some might argue otherwise, though.

[dstufft]

I'm not actually sure what a deprecation period would look like for something like this. We don't have a good way to message this I think, if we just message on any thing that might break with the new default we're going to produce a lot of false positives/noise. The only thing I could think of is implement an intermediate state where we switch to something like --use-pep517 by default, but if that fails for whatever reason we fall back to the legacy behavior.

I don't personally feel like that's a high value win, since I think a lot of the subtle issues have gotten worked out now, and I think that --no-use-pep517 is not a particularly onerous burden.

I do think it would be worthwhile to wait until next year for this change, I think 20.3 is close enough now that sneaking it in would be counterproductive AND I think the new resolver is a big enough change on it's own that this change would only muddy the waters.

[pradyunsg]

Given that we currently have a fairly non-trivial performance penalty to using PEP 517, I'm very much a -1 to making this switch without trying to address them. Thinking a bit more, there's also the issue of poor end-user control over isolated environments (our isolation also has bugs, but I'm too tired to locate them right now). Unless we address these two concerns, I expect this to cause more churn than our original PEP 517 rollout.

I'd consider things like #7294, #9081 to be essential pre-requisites for this -- overall, I feel like there's a lot of need for improvements to PEP 517's quality-of-implementation based on all the things we've learned and the changes in pip, since the original implementation.

It'd be a good thing if we can make it so that this doesn't make pip's own test suite slower. :)

[pradyunsg]

That said, I'm very very on board to actually figuring out what all do we consider as critical path to doing this.

[xavfernandez]

FWIW I agree with Pradyun that our PEP 517 implementation should first be improved (#7294 & #9081 are great examples) before making it the default.

[pfmoore]

This is probably true (it hadn't occurred to me because I tend to think of build isolation as a separate thing, because it was introduced with PEP 518 support, not with PEP 517). Is anyone planning to work on those two issues? They are both marked as "needs discussion", and I'd be very keen on not having the path to making PEP 517 the default blocked by proposals we can't decide on.

[pradyunsg]

I think the discussion needed on those two, at least, is how the implementation looks and not whether we wanna do them.

[jaraco]

As maintainer of Setuptools, I've been trying to wean myself off of environments where setuptools is installed. I've been using get-pip.py --no-setuptools and virtualenv --no-setuptools and aggressively uninstalling setuptools from whatever environments I can. Doing so causes problems: packages fail to install (no module named setuptools) and when they fail to install, backtracking causes lots of failed attempts. Passing --use-pep517 works around the issue, but that's clumsy. In my opinion, if PEP-517 installs are recommended and the default for projects to opt into, then they should be suitable for projects in general. I'd very much like to see this change enacted as soon as bearable.

[hroncok]

I've mentioned this issue in https://discuss.python.org/t/pip-without-setuptools-could-the-experience-be-improved/11810 -- my idea is that pip might want to default to --use-pep517 at least when setuptools is not installed.

[jaraco]

I found one case where --use-pep517 breaks the build. My advice would be to migrate the project to a more conventional structure, but I wanted to share here for context.

[uranusjr]

default to --use-pep517 at least when setuptools is not installed

This makes sense to me. And it could be a sensible way to move things forward as well since our current problem is blanket-defaulting to --use-pep517 is much too disruptive, but without this being a default there’s little incentive for offending packages to fix their build chain. We could, say, convince CPython to not provision populate setuptools in ensurepip, or ask virtualenv to only install pip by default. But I’m getting too much ahead of myself.

[pradyunsg]

We "control" both those modes -- the reason that setuptools and virtualenv ship setuptools, is because pip depends on them. Once we default to PEP 517 workflows, we'll need to go around and remove setuptools from the default shipped packages as well.

[uranusjr]

Yes, but the “problem” is that we are currently unable to come up with a scenario that not shipping setuptools is a good practical idea; even though we have a “long term goal” to remove it, it’s unclear how we can move closer to the goal. Those who are (still currently) publishing non-PEP-517 projects have little incentive to move to PEP 517 because every environment comes with setuptools and only packaging nerds contrieve weird scenarios where setuptools is unavailable, and we can’t make removing setuptools a less weird scenario because way too many packages are non-installable by default in this situation. It’s a circular dependency.

By making --use-pep517 the default behaviour, most of those non-PEP-517 packages will no longer be non-installable without setuptools. With that, we can more confidently advertise that creating an environment without seeding setuptools is not actually a weird choice because it works for most of the things. And thus the cycle can be broken.