docker-library / python

Docker Official Image packaging for Python

Home Page:https://www.python.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

gcc is missing in slim images for Python 3.10

dym-ok opened this issue · comments

I discovered today that despite having gcc in the list of installed packages it's not present result images:

docker run -it --rm python:3.10-slim-bookworm gcc -v
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "gcc": executable file not found in $PATH: unknown.

It's still there in normal Python 3.10 images:

docker run -it --rm python:3.10-bookworm gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

It seems related to #869

Those dependencies are only installed temporarily to build the image and are purged in the same layer so they don't end up in the final image. If you need it for your dependencies, you need to install it again.

This is a recent change of behavior, what would be advised in the context of CI environment, switching to non-slim versions?

It rather difficult to make sure that none of the (transient) dependencies would not require building a wheel.

Either use non-slim, or install GCC, install your dependencies and remove GCC in the same layer (same RUN command )

Thanks for the suggestion, @LaurentGoderre.

In our case we're building an image that is used in GitHub CI to support workflows of arbitrary projects, based on Python and Poetry, do dependencies are not included within the Docker image, but are installed during the workflow run, so having gcc is necessary.

I tried finding the official purpose/goals for the -slim version of images and I wasn't able to. I imagine it aims to support use cases, that focus on providing a Python environment for a well-defined list of dependencies, which will be installed inside the target Docker image using multi-stage builds. Is that a valid assumption?

@dym-ok yes. I wouldn't use the slim variant as a CI image

The non-slim images are "batteries included" based on https://hub.docker.com/_/buildpack-deps, which I think might help you tease this out a little:

The main tags of this image are the full batteries-included approach. With them, a majority of arbitrary gem install / npm install / pip install should be successful without additional header/development packages.

(Which seems to match your use case pretty exactly.)

The "slim" tags are then the antithesis to that: namely, not batteries included, and having only the bare minimum installed.