Repository navigation
Regression : ModuleNotFoundError: No module named 'pkg_resources' on python:3.12-slim #957
Description
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.
Activity
LaurentGoderre commentedon Sep 4, 2024
This was intentional see #952 and #954 for details
Nastaliss commentedon Sep 4, 2024
Thank you, didn´t see that.
Closing.
edmorley commentedon Sep 4, 2024
@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 onsetuptools.ie: it needs to add setuptools to its
install_requireslist insetup.py(or similar), or else migrate away from usingpkg_resourcesto 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
setuptoolsandwheelto your dependencies list inpyproject.toml. For cases where setuptools is used at run-time only (such as when you see theModuleNotFoundError: No module named 'pkg_resources'error), onlysetuptoolsneeds to be added to your dependencies - you should be able to omitwheel.rsomani95 commentedon Sep 4, 2024
@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 commentedon Sep 4, 2024
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'svenvmodule, the standalonevirtualenvpackage, 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 addsetuptoolsto yourDockerfileor requirements file as a workaround in the meantime.chore: remove wheel