python:3.14-trixie ships multiple Python versions via buildpack-deps base image

[mzakarian]

Description

When using the python:3.14-trixie image (non-slim variant), multiple Python versions are present in the final image due to the use of buildpack-deps:trixie as the base image.

In addition to the requested Python version provided by the Dockerfile, Debian-packaged Python versions are also installed via APT, which can lead to ambiguity and unexpected behavior when tools rely on /usr/bin/python3 or python3 from PATH.

---

Observed Behavior

The python:3.14-trixie image contains at least the following Python installations:

• Python 3.13.5-1 from the Debian python3 package
• Python 3.13.5-2 from the Debian python3.13 package
• Python 3.14.x installed by the Dockerfile under /usr/local

This happens because buildpack-deps:trixie pulls in Debian’s default Python packages as part of its dependency set.

As a result:

• /usr/bin/python3 points to Debian’s Python (3.13)
• /usr/local/bin/python3 points to the requested Python (3.14)
• Some tooling and scripts may accidentally pick up the wrong interpreter

---

Expected Behavior

Ideally, the image would:

• Contain only one Python version, or
• At least not include competing Debian-provided Python interpreters by default

This would reduce ambiguity and make the runtime behavior more predictable, especially for build tools, virtual environments, and scripts that assume a single python3.

---

Reference

Dockerfile in question:
https://github.com/docker-library/python/blob/master/3.14/trixie/Dockerfile

---

Questions / Discussion Points

1. Is it feasible to use debian:trixie as the base image for the non-slim variant as well (similar to how the slim images are built), instead of buildpack-deps?
2. Alternatively, would it be acceptable to explicitly remove Debian’s python3 / python3.13 packages in the Dockerfile after the build dependencies are installed?
3. Is the presence of multiple Python versions in python:*-trixie considered expected and stable behavior going forward?

I understand that buildpack-deps is intentionally “heavy” and optimized for build scenarios, but the resulting multiple Python installations are somewhat surprising from a runtime image consumer’s perspective.

Happy to provide a minimal reproducer or test case if that helps.

Thanks for maintaining the official Python images 🙏

[tianon]

This is documented at https://hub.docker.com/_/python#multiple-python-versions-in-the-image 😅

In the non-slim variants there will be an additional (distro-provided) python executable at /usr/bin/python (and/or /usr/bin/python3) while the desired image-provided /usr/local/bin/python is the default choice in the $PATH. This is an unfortunate side-effect of using the buildpack-deps image in the non-slim variants (and many distribution-provided tools being written against and likely to break with a different Python installation, so we can't safely remove/overwrite it).