How about updating setuptools, wheel, pip and installing setuptools-scm from git?

[KOLANICH]

Rationale: the stuff mentioned has a very long release cycle. It takes a while before features and fixes available in git are landed into release. I have been using the bleeding edge stuff from git in CI (installed manually upon python:latest) for a long time and experienced no problems with it, only benefits. So I think it may make sense to include this stuff into the images to ship it by default.

What does the community think about it?

[tao12345666333]

I think the official image is a foundation core, and it should provide a stable version of the tool, users can upgrade if necessary. There is no need to do this in the official image.

[tianon]

See also docker-library/ruby#255, where we're actively taking Ruby in the opposite direction of this proposal (ie, leaving the versions of Bundler and RubyGems alone and simply providing whatever the particular Ruby release comes with).

IMO it'd be interesting/useful to have a similar conversation with the Pip (and/or Python) maintainers and see whether they feel like it would be better for us to continue bumping Pip to the latest release or whether we should instead level that off and eventually simply provide whatever version of Pip that Python comes with by default (as we're now doing with Ruby).

[riconnon]

Also related:
#511

I think the comment by @tianon would be a good approach, pinning the versions of the core packages for the duration of a Python release series.

[tianon]

The recent breaking changes in setuptools make this a bit more urgent IMO. 😞

In looking into the details of how to implement this, my plan was to pin everything to whatever's the latest minor release of each today, with the plan in the future to be pinning to the minor release track that's included with the associated Python release (for example, if Python 3.11 contains PIP 22.x, we'd pin to that same 22.x for the duration of Python 3.11).

I can find the appropriate versions for both pip and setuptools no problem in https://github.com/python/cpython/blob/3.10/Lib/ensurepip/__init__.py, but I cannot seem to figure out how wheel relates to these two.

Is it only included by default because it's a useful CLI tool for dealing with wheel files, and not because either of these two modules use it directly? 😩

[vikahl]

Is it only included by default because it's a useful CLI tool for dealing with wheel files, and not because either of these two modules use it directly?

I am nowhere near an expert on this, but I got curious and tried to dig

Pip builds wheels for dependencies by default, if the wheel module is installed. I have however not found any link between versions for Pip/Setuptools and Wheels, nor any documentation on compatibility.

I assume that wheel use semantic versioning so pinning to <1 would be one way, another would be to leave it as is (and not pin) since that would mimic get-pip.py's behaviour.