Support manylinux and musllinux wheels

[EpicWink]

Currently, manylinux wheels using all libraries specified by manylinux (PEP 513, PEP 571, PEP 599, and PEP 600) and musllinux (PEP 656) will fail on the Docker-library Python images. I'm suggesting to either add these libraries to the images, or create new tags fulfilling the manylinux/musllinux expectations.

For both manylinux and musllinux, current community definition of "mainstream" distribution default libraries is specified in the manylinux repo.

Each image is missing:

• Full Debian Python 3.10: libgl1 (36.3MB of packages to download, 148MB installed)
• Slim Debian Python 3.10: libgl1 libglib2.0-0 libice6 libsm6 libx11-6 libxext6 libxrender1 zlib1g (39.8MB of packages to download, 158MB installed)
• Alpine Python 3.10: bzip2 db libcurl libidn2 openssl tk xz (22MiB installed)

[yosifkit]

tk is removed on purpose in Alpine based images so that users who need it can add it back in: #484 (comment). The Alpine images are also meant to be as small as possible. With the image being currently just 48.7MB on disk, a 22MiB increase would be a significant amount.

This variant is useful when final image size being as small as possible is your primary concern.

- https://github.com/docker-library/docs/tree/7a85537b34a6fcef752959975c16910e38e35d03/python#pythonversion-alpine

The debian-based slim images are smaller on purpose:

This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run python.

- https://github.com/docker-library/docs/tree/7a85537b34a6fcef752959975c16910e38e35d03/python#pythonversion-slim

The "regular" images are already overly large; at 922MB, adding 148MB would still be significant. It is not really meant to have every package for every possible pip installed dependency especially for something like graphical applications. If a user needs more libraries than are provided, then they need to install them.

[EpicWink]

That makes sense, although I disagree about the size concern of the full Debian image.

What's the argument against releasing new tags?

In any case, I think it's fine to wait to see if there's interest in the community for the Docker library Python images to support manylinux wheels. If not, this issue at least documents the missing libraries.

[tianon]

What's the argument against releasing new tags?

We already support a pretty obscene matrix of versions/variants (36 unique across ~9-10 unique architecture/platform combinations). 😬

Given using X11 and OpenGL are very uncommon inside container use cases, I'm very much inclined to suggest this is working-as-designed. 🙈

Documentation lives in https://github.com/docker-library/docs if you wanted to take a stab at documenting this better, however I don't think we should spend a lot of time/space on it (we're very limited on how much we can actually publish to the Docker Hub image description).