Deprecate the setup.py bdist_wheel code path

[sbidoul]

Towards #6334
Towards #9175
Towards #11859

[sbidoul]

About the timeline, would it make sense to remove support for setup.py bdist_wheel and setup.py develop at the same time?

[notatallshaw]

I am strongly -1 on an accelerated deprecation period (normal period is two releases, e.g. 25.1 -> 25.3), uv is keeping track of projects they have encountered that don't work with PEP 517: astral-sh/uv#2252, there are likely many more that don't use uv or aren't public, what is special about this that we are not giving them a normal notice period to fix their projects?

Here are some more details about why thee setuptools/wheel issue still occurs under PEP 517: #13314 (comment)

[sbidoul]

It is important to note that bdist_wheel and the default build backend (setuptools.build_meta:__legacy__) behave very similarly.

The main source of breakage will be build isolation by default.

At some point, I was considering to use PEP 517 without build isolation by default for projects without pyproject.toml, but in the end I think it would introduce an additional variation and source of confusion.

[sbidoul]

Should we consider the release planning of Python 3.14 to decide on the timeline for this deprecation?

[pfmoore]

Why will that make a difference? Are you thinking about whether Python 3.14 ships with a version of pip that drops the legacy code path? I'd hope that most people would upgrade their existing pip much more quickly than they'd upgrade their Python version - especially people who are still using the legacy code path (and I therefore assume to be relatively cautious in their upgrade policy).

IMO, we either follow our normal process (25.3, in October), or accelerate (25.2, in July).

Python 3.14 is scheduled for release on 7th October, so 25.2 would be well in advance of 3.14, whereas 25.3 would be fairly shortly after. I would expect 3.14 to ship with 25.2, on that basis.

[notatallshaw]

FWIW, the spec says there should be some user options to workaround package backend issues, but not something that package authors can rely on:

build frontends SHOULD provide some mechanism for users to override the above defaults. For example, a build frontend could have a --build-with-system-site-packages option that causes the --system-site-packages option to be passed to virtualenv-or-equivalent when creating build environments, or a --build-requirements-override=my-requirements.txt option that overrides the project’s normal build-requirements.

The general principle here is that we want to enforce hygiene on package authors, while still allowing end-users to open up the hood and apply duct tape when necessary.

Pip provides --no-build-isolation, but I don't think anything that can directly override the backend requirements.

[sbidoul]

Alright, I have updated to 25.3, and aligned the removal of setup.py develop to the same release (#13316).

[ichard26]

I'm not convinced that six months will be enough, but I'm fine with getting the ball rolling.

The linked deprecation issue is going to need a good write-up since I suspect this will be one of our frequently-hit deprecations. I'm happy to write one, but I won't have time until at the bare minimum Wednesday.

[sbidoul]

The linked deprecation issue is going to need a good write-up since I suspect this will be one of our frequently-hit deprecations. I'm happy to write one, but I won't have time until at the bare minimum Wednesday.

Agreed. Currently it's @pfmoore 's original #6334 from 6 years ago. We can either update it, or create another one.

[sbidoul]

@pradyunsg I see you self assigned this for review. So... last call before departure to 25.1 :)

[sbidoul]

I drafted a first set of recommendations in #6334.