Numpy fails in Pycharm but runs on VSCode/terminal M1 Mac
Question:
My code uses matplotlib which requires numpy. I’m using pipenv as my environment. When I run the code through my terminal and pipenv shell, it executes without a problem. I’ve just installed Pycharm for Apple silicon (I have an M1) and set up my interpreter to use the same pipenv environment that I configured earlier. However, when I try to run it through Pycharm (even the terminal in pycharm), it throws me the following error:
Original error was: dlopen(/Users/s/.local/share/virtualenvs/CS_156-UWxYg3KY/lib/python3.8/site-packages/numpy/core/_multiarray_umath.cpython-38-darwin.so, 0x0002): tried: '/Users/s/.local/share/virtualenvs/CS_156-UWxYg3KY/lib/python3.8/site-packages/numpy/core/_multiarray_umath.cpython-38-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e'))
What’s confusing me is the fact that my code executes when using this same environment through the my terminal… But it fails when running on Pycharm? Any insights appreciated!
Answers:
I’m not sure what the problem is, but it seems to be related to the fact that you’re using a different architecture (x86_64) than what’s required (arm64e). Try setting your Pycharm interpreter to use the same architecture as your terminal (arm64e) and see if that fixes the problem.
Macs with m1 chips have something called Rosetta. This is basically simualting the architecture of Intel and Amd chips. When you click on the properties of your terminal there should be an option to open the terminal with Rosetta.
I had the same problem already, in each IDE you can set if the script should be run with imulatation (Rosetta) or without. So you should look up how to tell pycharm to use Rosetta.
Set the "shell path" under preferences – tools – terminal:
env /usr/bin/arch -x86_64 /bin/zsh --login
that should fix it
The problem ended up being the python version I had installed. Since I upgraded from intel to M1, the python version also carried over. Downloading a new 3.10 version and creating a new interpreter for it solved this issue.
My code uses matplotlib which requires numpy. I’m using pipenv as my environment. When I run the code through my terminal and pipenv shell, it executes without a problem. I’ve just installed Pycharm for Apple silicon (I have an M1) and set up my interpreter to use the same pipenv environment that I configured earlier. However, when I try to run it through Pycharm (even the terminal in pycharm), it throws me the following error:
Original error was: dlopen(/Users/s/.local/share/virtualenvs/CS_156-UWxYg3KY/lib/python3.8/site-packages/numpy/core/_multiarray_umath.cpython-38-darwin.so, 0x0002): tried: '/Users/s/.local/share/virtualenvs/CS_156-UWxYg3KY/lib/python3.8/site-packages/numpy/core/_multiarray_umath.cpython-38-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e'))
What’s confusing me is the fact that my code executes when using this same environment through the my terminal… But it fails when running on Pycharm? Any insights appreciated!
I’m not sure what the problem is, but it seems to be related to the fact that you’re using a different architecture (x86_64) than what’s required (arm64e). Try setting your Pycharm interpreter to use the same architecture as your terminal (arm64e) and see if that fixes the problem.
Macs with m1 chips have something called Rosetta. This is basically simualting the architecture of Intel and Amd chips. When you click on the properties of your terminal there should be an option to open the terminal with Rosetta.
I had the same problem already, in each IDE you can set if the script should be run with imulatation (Rosetta) or without. So you should look up how to tell pycharm to use Rosetta.
Set the "shell path" under preferences – tools – terminal:
env /usr/bin/arch -x86_64 /bin/zsh --login
that should fix it
The problem ended up being the python version I had installed. Since I upgraded from intel to M1, the python version also carried over. Downloading a new 3.10 version and creating a new interpreter for it solved this issue.