multiarch support for Python

[vielmetti]

It would be excellent to have multiarch support for the Python official image, for as many platforms as possible that would have language support.

Happy to talk to anyone working on this to coordinate efforts, especially around multiarch for Raspberry Pi and ARMv8 builds.

[yosifkit]

It is currently a work in progress; official stance is here. So we do build https://hub.docker.com/r/armhf/python/ and https://hub.docker.com/r/aarch64/python/. We are working to support multiple architectures directly with the beginning at docker-library/official-images#2289.

[jaymoulin]

Is there any statement on this? images seems to be available but are unable to be downloaded on amd64 architecture for cross-compilation

[tianon]

Images are definitely available: https://hub.docker.com/_/python/ (see "Supported architectures", amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, ppc64le, s390x, windows-amd64)

This was simply left open on accident.

[tianon]

To download non-amd64 images on an amd64 box, you'll need to use the architecture-specific repos, as described in https://github.com/docker-library/official-images#architectures-other-than-amd64.

[jaymoulin]

I think this issue is still relevant

[jmoulin:~] $ docker pull arm32v7/python
Using default tag: latest
latest: Pulling from arm32v7/python
no matching manifest for linux/amd64 in the manifest list entries
[jmoulin:~] 1 $ docker pull arm32v7/erlang
Using default tag: latest
latest: Pulling from arm32v7/erlang
Digest: sha256:70e98c99ea5223f15a30611830399a9092556ff54d19cbce9ea1e3fb780920f8
Status: Image is up to date for arm32v7/erlang:latest
[jmoulin:~] $ manifest-tool inspect arm32v7/python
Name:   arm32v7/python (Type: application/vnd.docker.distribution.manifest.list.v2+json)
Digest: sha256:3b161c1a0e62141b575e070168997d0be7eed9067d0ff227f03809b2ac010490
 * Contains 1 manifest references:
1    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
1       Digest: sha256:498d2f77f9a8156c4c4cc8c72bf59dcae22759094ba980014fb551aa7f925563
1  Mfst Length: 2007
1     Platform:
1           -      OS: linux
1           - OS Vers: 
1           - OS Feat: []
1           -    Arch: arm
1           - Variant: v7
1           - Feature: 
1     # Layers: 8
         layer 1: digest = sha256:e52c47bf5ccb0baf5e58ae2e958abbb260f942d8743078a07a367079102e162f
         layer 2: digest = sha256:fd486ac73440295f728f6eadb49eabdf58a6cad76cf3c8e36ef7a32894278271
         layer 3: digest = sha256:6d7f3d3c242c5c32ebca96ff0585d5c4a69396ff61b65045a636b1b3368b15b2
         layer 4: digest = sha256:c4284e173e9bce8ed8b43c6744e98d30ea5da563719dcf431bbca74a990d5ba5
         layer 5: digest = sha256:760929ae27ae07d5c38ab85f323952c3dda6023ae08414ce88d5470cac500d57
         layer 6: digest = sha256:81519b412b12141d1b847ab878365c01f1f162c0495302d37e800f8d2192f84f
         layer 7: digest = sha256:aeec573a65f7407ee61e0f4851293b2294ee41bfcf2326979cd90a345247903a
         layer 8: digest = sha256:a6115fe7ba1ec17032c64733fae390db17c9d19635db2c91d69c271215de0146

[jmoulin:~] 5s $ manifest-tool inspect arm32v7/erlang
arm32v7/erlang: manifest type: application/vnd.docker.distribution.manifest.v2+json
      Digest: sha256:70e98c99ea5223f15a30611830399a9092556ff54d19cbce9ea1e3fb780920f8
Architecture: arm
          OS: linux
    # Layers: 7
      layer 1: digest = sha256:e52c47bf5ccb0baf5e58ae2e958abbb260f942d8743078a07a367079102e162f
      layer 2: digest = sha256:fd486ac73440295f728f6eadb49eabdf58a6cad76cf3c8e36ef7a32894278271
      layer 3: digest = sha256:6d7f3d3c242c5c32ebca96ff0585d5c4a69396ff61b65045a636b1b3368b15b2
      layer 4: digest = sha256:c4284e173e9bce8ed8b43c6744e98d30ea5da563719dcf431bbca74a990d5ba5
      layer 5: digest = sha256:0cd5810ff4a3aeac399b3b9b35de3ce2fc424a8beafcbc03c652c51bd17f4f45
      layer 6: digest = sha256:b6fec8c2931cffd24bb0a31507d992dd279fb3c8a72d9f09eb35838c0e9992ac
      layer 7: digest = sha256:322c777325c45c2f83d54e675eb8001bdd08458f7bb421be427f33952a3d8d2c

Version:

$ docker --version
Docker version 17.11.0-ce, build 1caf76c

[jaymoulin]

Should I open a new ticket or you can reopen this one?

[tianon]

python:latest is a "shared tag", which means it's implemented via manifest list (and thus Docker balks at "unsupported" platforms) -- use a more specific tag, and you'll get a more useful result:

$ docker pull arm32v7/python:3.6-jessie
3.6-jessie: Pulling from arm32v7/python
e52c47bf5ccb: Downloading [================>                                  ]  16.23MB/48.69MB
...

[jaymoulin]

OK. What about alpine then?

[jmoulin:~] $ docker pull arm32v7/python:alpine
Error response from daemon: manifest for arm32v7/python:alpine not found
[jmoulin:~] 1 $ docker pull amd64/python:alpine
alpine: Pulling from amd64/python
Digest: sha256:e140d79791cfb0d6613b37b4d6acb7b2b2de95fdfbefa7b181f8f99561818d83
Status: Image is up to date for amd64/python:alpine

[tianon]

Alpine doesn't support arm32v7, see arm32v6: https://hub.docker.com/r/arm32v6/python/

[tianon]

(so, docker pull arm32v6/python:3.6-alpine3.6, for example)

[jaymoulin]

OK. What about have the same names then?

[jmoulin:~] 1 $ docker pull amd64/python:alpine
alpine: Pulling from amd64/python
Digest: sha256:e140d79791cfb0d6613b37b4d6acb7b2b2de95fdfbefa7b181f8f99561818d83
Status: Image is up to date for amd64/python:alpine
[jmoulin:~] 8s $ docker pull arm32v6/python:alpine
Error response from daemon: manifest for arm32v6/python:alpine not found
[jmoulin:~] 1 $ docker pull arm32v6/python:alpine3.6
alpine3.6: Pulling from arm32v6/python
0864efeeb5cb: Pull complete 
3cda69762aee: Pull complete 
8815f8619ffb: Downloading [==>                                                ]  16.38kB/352.1kB
a361ac515bc4: Waiting 
ef6ef7256771: Waiting 
940f83c78a12: Waiting 

[yosifkit]

python:alpine is not equivalent to python:alpine3.6 since just alpine refers to the alpine:3.4 based image and only alpine 3.6 has multiple architectures. See https://hub.docker.com/_/python/ (and each arch) for the list of available tags.

[jaymoulin]

Shouldn't alpine refers the latest version of alpine?

[tianon]

See docker-library/golang#131 (comment) for some discussion about why we can't simply make that change (and why alpine stays consistent for now). Perhaps at some point in the future (when we've made -alpine3.4 variants more explicit and normalized) we can consider revisiting that policy.