BUG: <ImportError when running container on M1 mac laptop>

[janeswh]

Describe the issue:

I built a multiplatform Docker image using Linux and installed numpy via requirements.txt file. The container runs fine on both Windows and Linux but when running it on Mac (linux/arm64), the following error is displayed. Forcing Docker on Mac to use the linux/amd64 platform resolves the error, so I'm wondering whether it's a Python 3.11/arm/numpy interaction issue?

python version: 3.11
numpy version: 1.25.0
Mac OS 12.5

Reproduce the code example:

import numpy as np

Error message:

Traceback (most recent call last):
  File "/opt/venv/lib/python3.11/site-packages/numpy/core/__init__.py", line 23, in <module>
    from . import multiarray
  File "/opt/venv/lib/python3.11/site-packages/numpy/core/multiarray.py", line 10, in <module>
    from . import overrides
  File "/opt/venv/lib/python3.11/site-packages/numpy/core/overrides.py", line 8, in <module>
    from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/venv/bin/streamlit", line 5, in <module>
    from streamlit.web.cli import main
  File "/opt/venv/lib/python3.11/site-packages/streamlit/__init__.py", line 55, in <module>
    from streamlit.delta_generator import DeltaGenerator as _DeltaGenerator
  File "/opt/venv/lib/python3.11/site-packages/streamlit/delta_generator.py", line 36, in <module>
    from streamlit import config, cursor, env_util, logger, runtime, type_util, util
  File "/opt/venv/lib/python3.11/site-packages/streamlit/cursor.py", line 18, in <module>
    from streamlit.runtime.scriptrunner import get_script_run_ctx
  File "/opt/venv/lib/python3.11/site-packages/streamlit/runtime/__init__.py", line 16, in <module>
    from streamlit.runtime.runtime import Runtime as Runtime
  File "/opt/venv/lib/python3.11/site-packages/streamlit/runtime/runtime.py", line 31, in <module>
    from streamlit.runtime.app_session import AppSession
  File "/opt/venv/lib/python3.11/site-packages/streamlit/runtime/app_session.py", line 35, in <module>
    from streamlit.runtime import caching, legacy_caching
  File "/opt/venv/lib/python3.11/site-packages/streamlit/runtime/caching/__init__.py", line 21, in <module>
    from streamlit.runtime.caching.cache_data_api import (
  File "/opt/venv/lib/python3.11/site-packages/streamlit/runtime/caching/cache_data_api.py", line 32, in <module>
    from streamlit.runtime.caching.cache_errors import CacheError, CacheKeyNotFoundError
  File "/opt/venv/lib/python3.11/site-packages/streamlit/runtime/caching/cache_errors.py", line 18, in <module>
    from streamlit import type_util
  File "/opt/venv/lib/python3.11/site-packages/streamlit/type_util.py", line 40, in <module>
    import numpy as np
  File "/opt/venv/lib/python3.11/site-packages/numpy/__init__.py", line 139, in <module>
    from . import core
  File "/opt/venv/lib/python3.11/site-packages/numpy/core/__init__.py", line 49, in <module>
    raise ImportError(msg)
ImportError: 

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the numpy C-extensions failed. This error can happen for
many reasons, often due to issues with your setup or how NumPy was
installed.

We have compiled some common reasons and troubleshooting tips at:

    https://numpy.org/devdocs/user/troubleshooting-importerror.html

Please note and check the following:

  * The Python version is: Python3.11 from "/opt/venv/bin/python3"
  * The NumPy version is: "1.25.0"

and make sure that they are the versions you expect.
Please carefully study the documentation linked above for further help.

Original error was: No module named 'numpy.core._multiarray_umath'


Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

Runtime information:

numpy doesn't run on Mac docker container

Context for the issue:

No response

[mattip]

On 5/7/23 00:50, janeswh wrote: Describe the issue: I built a multiplatform Docker image using Linux and installed numpy via requirements.txt file. The container runs fine on both Windows and Linux but when running it on Mac (linux/arm64), the following error is displayed. Forcing Docker on Mac to use the linux/amd64 platform resolves the error, so I'm wondering whether it's a Python 3.11/arm/numpy interaction issue? python version: 3.11 numpy version: 1.25.0 Mac OS 12.5

Are you using exactly the same binary image in each run (windows, linux, mac) from an image hub or rebuilding for each platform's docker? How did you install python? What is reported for `python3.10 -c "from packaging import tags; print([str(t) for t in tags.sys_tags()][:10])"` in each of the docker runs (windows, linux, macos, macos-x86_64)? Matti

…

Message ID: ***@***.***>

[janeswh]

Are you using exactly the same binary image in each run (windows, linux,
mac) from an image hub or rebuilding for each platform's docker?

I'm rebuilding for each platform's docker using TARGETPLATFORM in my Dockerfile, then platforms: linux/arm64, linux/amd64 in the docker/build-push-action portion of my Github action .yml file

How did you install python?

Not sure what you mean.. for the Docker image, it's a multistage build with FROM --platform=$BUILDPLATFORM python:3.11-slim-bookworm AS build and after pip installing everything, FROM python:3.11-slim-bookworm AS runtime .

On the Linux computer where I'm doing the building, it was sudo apt install Python 3.11 then using it in a venv; I'm using PopOS and it already came with system Python 3.10

What is reported for python3.10 -c "from packaging import tags; print([str(t) for t in tags.sys_tags()][:10])" in each of the docker
runs (windows, linux, macos, macos-x86_64)?

I changed the above command to python3.11

Windows

['cp311-cp311-manylinux_2_36_x86_64', 'cp311-cp311-manylinux_2_35_x86_64', 'cp311-cp311-manylinux_2_34_x86_64', 'cp311-cp311-manylinux_2_33_x86_64', 'cp311-cp311-manylinux_2_32_x86_64', 'cp311-cp311-manylinux_2_31_x86_64', 'cp311-cp311-manylinux_2_30_x86_64', 'cp311-cp311-manylinux_2_29_x86_64', 'cp311-cp311-manylinux_2_28_x86_64', 'cp311-cp311-manylinux_2_27_x86_64']

Linux

['cp311-cp311-manylinux_2_36_x86_64', 'cp311-cp311-manylinux_2_35_x86_64', 'cp311-cp311-manylinux_2_34_x86_64', 'cp311-cp311-manylinux_2_33_x86_64', 'cp311-cp311-manylinux_2_32_x86_64', 'cp311-cp311-manylinux_2_31_x86_64', 'cp311-cp311-manylinux_2_30_x86_64', 'cp311-cp311-manylinux_2_29_x86_64', 'cp311-cp311-manylinux_2_28_x86_64', 'cp311-cp311-manylinux_2_27_x86_64']

M1 macbook pro

['cp311-cp311-manylinux_2_36_aarch64', 'cp311-cp311-manylinux_2_35_aarch64', 'cp311-cp311-manylinux_2_34_aarch64', 'cp311-cp311-manylinux_2_33_aarch64', 'cp311-cp311-manylinux_2_32_aarch64', 'cp311-cp311-manylinux_2_31_aarch64', 'cp311-cp311-manylinux_2_30_aarch64', 'cp311-cp311-manylinux_2_29_aarch64', 'cp311-cp311-manylinux_2_28_aarch64', 'cp311-cp311-manylinux_2_27_aarch64']

macos-x86_64

['cp311-cp311-manylinux_2_36_x86_64', 'cp311-cp311-manylinux_2_35_x86_64', 'cp311-cp311-manylinux_2_34_x86_64', 'cp311-cp311-manylinux_2_33_x86_64', 'cp311-cp311-manylinux_2_32_x86_64', 'cp311-cp311-manylinux_2_31_x86_64', 'cp311-cp311-manylinux_2_30_x86_64', 'cp311-cp311-manylinux_2_29_x86_64', 'cp311-cp311-manylinux_2_28_x86_64', 'cp311-cp311-manylinux_2_27_x86_64']

[mattip]

Weird. According to that, you should already be running a x86_64-only python, so I am not sure how setting the arch to x86_64 helps "convince" the docker to use x86_64 mode.

[janeswh]

I'm a newbie to all this.. could you explain what you mean? Everything listed in the M1 macbook pro is aarch64, and that's where I'm setting the arch to x86_64 to (but then it just runs in emulation and everything is slow/defeats the purpose of the multiplatform build). The macos-x86_64 doesn't have problems running the image.

[mattip]

Ahh, no, I was reading on my phone and missed something. Look at the output from the M1 macbook pro. Note the tag names have aarch64 in them. This is a sign that the python you installed into your docker supports arm64 by default, which is the case when using a python downloaded from python.org: note how the installable links all say "Download macOS 64-bit universal2 installer". The "universal2" means that the python can run either as arm64 or as x86_64. But the wheels provided by pip install in general will be for one system or the other, not universal2. For some discussion, see this cibuildwheel issue, where the bottom line is to leave the choice up to the package. NumPy, like all the rest of the scientific python stack (qualifier: maybe not all, go ahead, it is the internet, prove me wrong), has chosen to not provide universal2 wheels. So you need to choose carefully when setting up your docker image for work with python: do you want to use arm64 or x86_64 packages. If you use x86_64, you must run the docker in x86_64 mode.

[janeswh]

Ah okay, that makes sense. Does this mean that my docker multi-platform build was done incorrectly, then? Here is the beginning part of my Dockerfile:

FROM --platform=$BUILDPLATFORM python:3.11-slim-bookworm AS build
ARG TARGETPLATFORM

ENV VIRTUAL_ENV=/opt/venv
RUN python3 -m venv $VIRTUAL_ENV
ENV PATH="$VIRTUAL_ENV/bin:$PATH"

COPY requirements.txt ./
RUN pip3 install -r requirements.txt

I assumed that by the time pip3 install is run, the arm64 image would do pip install numpy and get the arm64 package. How should I instead be telling the arm64 image in the Dockerfile to get arm64 numpy? Apologies in advance if I'm still misunderstanding anything!

[mattip]

We are off-topic for the NumPy issue tracker, sorry. Maybe stackoverflow could help? As a parting hint, I would carefully look at how you are setting things like TARGETPLATFORM and examine the output as you are running the docker build, maybe add some debugging output, so you can see what python is doing.

I will close this since it really has little to do with NumPy. We often get these kind of issues since NumPy is typically the first package installed, and sometimes can even help a bit, but I think we have gone as far as we can.