Stop installing setuptools and wheel by default

[edmorley]

Currently get-pip.py installs not only pip, but also setuptools and wheel by default, unless the --no-setuptools / --no-wheel (or PIP_NO_SETUPTOOLS / PIP_NO_WHEEL env vars) are used.

This has historically been necessary, however, modern versions of pip will now fallback to pyproject.toml (PEP 517) based builds (which will default to a setuptools backend, and thus automatically install setuptools and wheel in the isolated build environment) if either setuptools is not installed (as of pip 22.1), or if wheel is not installed (as of pip 23.1).

In addition, as of Python 3.12, the stdlib's ensurepip and venv modules no longer install setuptools, and only install pip.

As such, it seems like it might be time for get-pip.py to stop installing setuptools and wheel by default, in order to:

• act as another small step towards pyproject.toml / PEP 517 based builds eventually becoming the pip default. (Cross-reference: Default to isolated, pyproject.toml-based builds pip#9175)
• improve parity with the behaviour of latest ensurepip / venv
• allow get-pip.py to focus on its primary responsibility: bootstrapping pip

See also:

• Stop installing setuptools and wheel by default on Python 3.12+ environments virtualenv#2487
• Stop including setuptools and wheel in Python 3.12+ images docker-library/python#952

[pradyunsg]

A PR to stop doing this on Python 3.12+ would be welcome. I don't think we want to change the behaviour for older Python versions, but doing it on newer Python versions seems reasonable to me.

[edmorley]

A PR to stop doing this on Python 3.12+ would be welcome. I don't think we want to change the behaviour for older Python versions, but doing it on newer Python versions seems reasonable to me.

I can definitely see the appeal of having get-pip.py continue to install setuptools/wheel on Python < 3.12, since it will then mirror the behaviour of the stdlib's ensurepip and venv modules.

However, I do wonder whether it makes for a more confusing experience for users, given that to them get-pip's behaviour will appear to magically change if/when they upgrade their Python version in the future, even though get-pip isn't part of the stdlib and so to them shouldn't be affected by a Python version upgrade? (Particularly since at present, get-pip doesn't itself print info messages to stdout, so there isn't really a precedent for explaining to users why its skipping a step or not etc.)

As such, I personally think it might be best to make this change for all Python versions, so at least get-pip's behaviour is consistent and easier to explain in the docs?

[edmorley]

@pradyunsg What are your thoughts on the above? :-)

[edmorley]

I've opened #218 for this.