In terms of availability, I should have some (although not a lot!) time to review starting in mid-late October. If you want to wait for reviews (since this is a major change), then you may want to take that into consideration. Otherwise, it will depend on whether Paul, Pradyun or Damian have any time for reviews.

Anyway, thank you a lot for working on this!

I will try and add my review before 25.3, although this is really outside my wheelhouse (pun intended), so I'll only really be reviewing code quality and doing some smoke tests, I assume there aren't many design choices here, but if there are I won't be able to add much useful input.

Thanks @ichard26 and @notatallshaw ! I'll also try to make some time to review other 25.3 PRs in the coming 2 weeks.

Regarding this PR, there were not any design decisions left to do. So it's a big diff but it's straightforward removal of all non-pep517 code paths. The code base was already prepared for that thanks to the work we progressively did over the last (10?) years - kudos to everyone involved, by the way!

The vast majority of the changes to the test suite is adding --no-build-isolation in many places so tests don't have to look for setuptools. A few other tests had to be removed as they were testing removed features, or needed to be adjusted to cope with removed options (such as using --config-setting instead of --global-option).

Thanks for this @notatallshaw. I still need to update the documentation.

@sbidoul I am slowly reviewing this PR. I expect to be done in a few days. A few notes though:

• I don't think the InstallRequirement.isolated attribute is used anymore. It was only used by the legacy setuptools flows. Unless there is a possible future use for that attribute (maybe process isolation during build?), I'd prefer if we got rid of it. It's being passed around everywhere for no real gain.

• I'm not the biggest fan of adding --no-build-isolation everywhere since it does deviate from the normal installation flow. I'd prefer that we used a variation of pip_install_local() that passed --no-index¹ and --find-links pointing to the common wheels cache. However, doing that would be substantially slower since build isolation still has a major performance penalty (while Install build dependencies in-process #13450 will help a lot, just installing setuptools can be slow). Due to that, I agree it's better to use --no-build-isolation for now.

@ichard26 thanks!

I don't think the InstallRequirement.isolated attribute is used anymore

Did this PR do that? I don't immediately see it. If not I'd rather do that in another PR.

I'm not the biggest fan of adding --no-build-isolation everywhere [in the test suite]

Me neither. I had the same reasoning as you, plus I did not want to mix a huge refactor of the test suite in this PR so it remains feasible to review that the tests did not change what they intended to test.

Did this PR do that? I don't immediately see it. If not I'd rather do that in another PR.

@sbidoul, actually I double checked and it appears that InstallRequirement.isolated also influences the installation scheme when the distutils locations backend is used ( 😔). So I guess we can only remove the attribute when our distutils code is dead. (@uranusjr do you know what the timeline looks like for that?)

I updated the documentation by merging the index.md and pyproject-toml.md pages of the build-system directory into a single build-system.md page.

This is now ready to go.

I don't have any additional review comments, so If no one objects or beats me to it I plan to merge this tomorrow.

I do want to give this one more look-over, so as with my Direct URL PR, give me until EOD tomorrow to do so. If I don't review by EOD, go ahead w/o me.

Yeah, I did not get the chance (as I write this at 2am) to review this again. I'm wary of merging such a major PR this late into a development cycle and w/ very limited maintainer resources post-release, but if you're up for it, I won't block this PR either.

I'm not really worried about the risk. In any case I'll be around post release to followup on this if needed.

@sbidoul I believe you merging #13541 has created conflicts for this PR.

I resolved the conflict.

I'm wary of merging such a major PR this late into a development cycle and w/ very limited maintainer resources post-release

While it's a major PR it's not a conceptionally complex PR, it removes depreciated behavior from pip.

And I dont think a long period in main is going to help us find anything, very few people are running pip off the main branch, and PEP 517 is well validated in the wild.

All that is to say I am fine with releasing with this PR so I'm going to merge now!

Thanks so much @sbidoul, I'm not sure there's any other maintainer right now who has the motivation to do this, but it's important pip moves ever closer to standards complaince.

FWIW, this breaks a bunch of documentation URLs and we should add entries to the RTD redirects for them or, otherwise, not remove the pages.

Not sure if we need something beyond what's possible with https://github.com/pypa/pip/blob/main/.readthedocs-custom-redirects.yml today.

Indeed, good point @pradyunsg.

When you say "a bunch", do you have a mean to see a list somewhere, or is it just the two pages I have merged in place of the index page?

I guess it's those pages + anchors within them that have been broken. It ends up being more than two URLs, but is probably just those two pages.

Thinking a bit more about this though, I think we should keep the old docs for setup.py around for users who might be affected and need to understand what's changed between the two build systems as part of figuring out how migrate/be able to adapt to the "new" PEP 517 only world?

FWIW, I tried the pip main branch on zc.buildout and all its tests still passed. On a maintenance branch I needed two minor fixes to the tests because the output has changed slightly (we were checking for the presence of python setup.py egg_info in the output, which is no longer there after this PR, which is good).

I also tried it on the core development repo of Plone, both with zc.buildout and pip, and that went fine.

So: looking good. Thanks for carefully cleaning this up @sbidoul !

@mauritsvanrees thanks a lot for taking the time to provide feedback. Much appreciated.

I'm happy to submit or accept a PR to fix the broken links.

I'm a little less motivated by setup.py information, I'd rather point users to the packaging user guide where possible. But if someone wants to submit a PR that contains useful information I can accept it.