Stop installing setuptools in python 3.12+

[yosifkit]

This fixes the intent that was meant to happen in #833 of no longer including setuptools (or wheel).

Fixes #952.

If you are using Python 3.12+ and you have build or runtime dependencies on setuptools or wheel, a simple addition to your Dockerfile is all that is needed. (I think longer term, they might make sense as additions to your requirements.txt)

FROM python:3.12
WORKDIR /usr/src/app

### ⬇️ this line ⬇️ ##########################
RUN pip install --no-cache-dir setuptools wheel
###############################################

# continue your regular installation
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# ...

[tianon]

Suggested change

	--no-setup-tools \
	--no-setuptools \

https://github.com/pypa/get-pip/blob/ac9253767f0be4cdef620a3ca07187a8cabc66a5/README.md#get-pippy-options 👀

[yosifkit]

+ python -c import setuptools
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'setuptools'
+ python -c import wheel
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'wheel'

🤔 Maybe these could be 2>/dev/null

[tianon]

I guess relevant to #954 (comment), if we made these a dedicated script we could probably do a single script that's more complex, like catching the import exception directly in Python code instead?

[edmorley]

Thank you for opening this! :-)

[edmorley]

Longer term should these smoke tests live in docker-library/official-images where the other tests are? eg:
https://github.com/docker-library/official-images/tree/master/test/tests/python-imports
https://github.com/docker-library/official-images/tree/master/test/tests/python-no-pyc

[yosifkit]

Yeah, that makes sense. I removed them so they can just be in the test scripts.

[edmorley]

For completeness, and in case get-pip were to ever stop installing wheel by default for older Python versions, should we add wheel as an explicit dependency here (without a version specfier, to match the get-pip behaviour)?

ie:

Suggested change

	"setuptools==$PYTHON_SETUPTOOLS_VERSION" \
	"setuptools==$PYTHON_SETUPTOOLS_VERSION" \
	wheel \

[tianon]

Ah yeah, that's probably a good idea, even though I don't love it 😂 😭 ❤️

[edmorley]

I think the Windows template will need similar changes too:

python/Dockerfile-windows.template

Lines 74 to 81 in cc2cf19

	{{ if .setuptools then ( -}}
	('setuptools=={0}' -f $env:PYTHON_SETUPTOOLS_VERSION) \
	{{ ) else "" end -}}
	; \
	Remove-Item get-pip.py -Force; \
	\
	Write-Host 'Verifying pip install ...'; \
	pip --version; \

[edmorley]

I think it might also be worth updating the PR description to give an example of how to restore the previous behaviour, for the small subset of users who are are running pip with build isolation disabled, or have broken dependencies (that have run-time dependency on setuptools but that don't correctly list an explicit install_requires dependency on it).

For example:

FROM python:3

WORKDIR /usr/src/app

RUN pip install --no-cache-dir setuptools wheel
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# ...

(this is an adapted version of the Dockerfile usage example listed at https://hub.docker.com/_/python/)

[tianon]

docker-library/official-images#17446 👀 (I've verified that works with this PR's images, and fails on the current images)

[tianon]

(Close and reopen to force trigger new CI so it includes our updated test. 🙇 I've also got https://github.com/docker-library/python/actions/runs/10623880671 running fresh on master so we can see the failing baseline.)

[tianon]

Hilariously, thanks to pypa/get-pip#218, my "baseline" test on master is succeeding because now get-pip.py has the same behavior as this PR. 😂

[tianon]

Now we're being really explicit about it both directions, which feels right. 😄