Mac M1环境Docker容器安装旧版无ARM wheel的pyarrow/numpy问题咨询

Mac M1属于ARM64架构，Docker默认会拉取对应ARM64版本的python:3.8基础镜像。pyarrow==0.16.0、1.21版本以前的numpy都没有发布官方ARM64架构预编译wheel，在ARM64环境中执行pip install时，pip会自动拉取源码包本地编译。

两种操作表现不一致的本质是构建引擎的环境差异：

• 执行docker run进入交互容器时，Docker Desktop会自动完整挂载QEMU跨架构转译环境，编译过程中调用的gcc、cmake等工具链可以正常执行，源码编译可以跑完
• 默认开启的BuildKit构建引擎，在旧版本Docker Desktop中存在QEMU转译兼容缺陷：执行docker build的RUN指令时，不会正确继承宿主机的binfmt跨架构执行规则，C/C++编译过程中会出现进程异常、链接错误，直接导致编译失败。

方案1：强制使用amd64架构基础镜像（最稳定，推荐） #

直接指定基础镜像为linux/amd64平台，通过Rosetta 2转译运行x86版本容器，旧版pyarrow、numpy都有x86架构的预编译wheel，pip安装时直接下载预编译包，不需要本地编译，速度快无兼容问题。

修改Dockerfile第一行即可：

FROM --platform=linux/amd64 python:3.8

RUN apt update && apt install -y cmake
RUN pip install pyarrow==0.16.0

如果不想修改Dockerfile，也可以在构建命令中指定平台参数：

docker build --platform=linux/amd64 -t pyarrow .

注意：后续运行该镜像时，也建议带上--platform=linux/amd64参数，避免架构不匹配导致的运行异常。

方案2：关闭BuildKit使用传统构建引擎 #

如果必须使用原生ARM64镜像，可以临时关闭BuildKit，让构建过程的环境和普通docker run保持一致，源码编译流程可以正常执行。
构建前在终端执行环境变量配置，再执行构建命令：

export DOCKER_BUILDKIT=0
docker build -t pyarrow .

该方案缺点是源码编译速度极慢，pyarrow这类重型依赖编译通常需要15分钟以上，且如果缺失编译依赖还是会报错，稳定性弱于方案1。

方案3：预编译ARM64版本wheel托管到内部源 #

如果团队内M1设备较多，可以提前在ARM64环境下编译好所有需要的旧版本Python包的wheel，上传到公司内部PyPI源，后续构建时直接从内部源拉取预编译包，既可以用原生ARM64镜像的性能，也不需要每次构建都现场编译。

内容的提问来源于stack exchange，提问作者stucksam