Regression : ModuleNotFoundError: No module named 'pkg_resources' on `python:3.12-slim`

[Nastaliss]

When using the python:3.12-slim image, we now face the following error :

ModuleNotFoundError: No module named 'pkg_resources'

This was not the case two days ago.

It fails with docker.io/library/python:3.12-slim@sha256:106893e6c2aadd9168cc9cb3d8a305ebee8c0aac200e9395a05421ae2be4ed3d, but not with docker.io/library/python:3.12-slim@sha256:59c7332a4a24373861c4a5f0eec2c92b87e3efeb8ddef011744ef9a751b1d11c.

[LaurentGoderre]

This was intentional see #952 and #954 for details

[Nastaliss]

Thank you, didn´t see that.
Closing.

[edmorley]

@Nastaliss I would also report the issue upstream to whatever package you are using that is importing pkg_resources, since that package has a missing dependency on setuptools.

ie: it needs to add setuptools to its install_requires list in setup.py (or similar), or else migrate away from using pkg_resources to one of the newer APIs in the Python stdlib instead (such as importlib.metadata or importlib.resources).

Lastly, I notice in CyberCRI/projects-backend@39d1686 that you added both setuptools and wheel to your dependencies list in pyproject.toml. For cases where setuptools is used at run-time only (such as when you see the ModuleNotFoundError: No module named 'pkg_resources' error), only setuptools needs to be added to your dependencies - you should be able to omit wheel.

[rsomani95]

@LaurentGoderre we were running into this issue as well. We've come to use docker because of its reliabile reproduction of environments.

While I understand why this change was made, an intentional change like this breaks every docker image that used python:3.12-slim, and puts the burden on the user to keep themselves updated with the nitty gritties of changes made at a level that is one of the primary motivations to even use Docker. Besides, a container that's been built 1000s of times in the past few months suddenly breaks with no changes whatsoever because of a change in the base image provided by you guys. That does not seem like reasonable behavior to me.

I urge you to strongly reconsider whatever the decision making criteria is for making such changes. Luckily for us, we caught this when developing locally - I can imagine this being a bigger issue in a different scenario.

[edmorley]

breaks every docker image that used python:3.12-slim

Not that it helps your use-case (since you are obviously using one of the affected packages), but to be slightly more precise - it doesn't break every image - rather only those that are using a package that doesn't declare its dependencies properly (ie: packages that didn't add support for Python 3.12 properly when it was released last year).

Such packages were already broken with Python 3.12 (and thus python:3.12-slim) when used via Poetry (install --sync), uv sync, the stdlib's venv module, the standalone virtualenv package, GitHub Actions Python runtimes, and no doubt others.

The only scenario that happened to work was using python:3.12-slim's system installation directly with pip (ie: not using a venv, Poetry, or any of the other tools mentioned above) - and that was only because of an oversight in the way that Python 3.12 support was added to the Docker images in this repo (note the PR title and description in #833 mentions removing setuptools, but due to get-pip implementation details this didn't occur as expected).

So whilst this might be momentarily painful for any projects both using the python:3.12* images and one of the affected (broken) packages - I would encourage using this as an opportunity to report Python 3.12 compatibility issues upstream to the affected packages (which benefits everyone, including people who weren't using these images, and for whom those packages already didn't work), and whilst waiting for upstream fixes, to add setuptools to your Dockerfile or requirements file as a workaround in the meantime.