Repository navigation
Closed
Description
(venv) grigoryvorobiev@MacBook-Pro-Grigory pythonProject1 % python main.py
Traceback (most recent call last):
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/main.py", line 1, in <module>
from google.cloud import translate
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/google/cloud/translate/__init__.py", line 17, in <module>
from google.cloud.translate_v3.services.translation_service.client import (
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/google/cloud/translate_v3/__init__.py", line 17, in <module>
from .services.translation_service import TranslationServiceClient
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/google/cloud/translate_v3/services/translation_service/__init__.py", line 16, in <module>
from .client import TranslationServiceClient
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/google/cloud/translate_v3/services/translation_service/client.py", line 25, in <module>
from google.api_core import gapic_v1 # type: ignore
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/google/api_core/gapic_v1/__init__.py", line 16, in <module>
from google.api_core.gapic_v1 import config
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/google/api_core/gapic_v1/config.py", line 23, in <module>
import grpc
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/grpc/__init__.py", line 22, in <module>
from grpc import _compression
File "/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/grpc/_compression.py", line 15, in <module>
from grpc._cython import cygrpc
ImportError: dlopen(/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/grpc/_cython/cygrpc.cpython-310-darwin.so, 0x0002): tried: '/Users/grigoryvorobiev/PycharmProjects/pythonProject1/venv/lib/python3.10/site-packages/grpc/_cython/cygrpc.cpython-310-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/lib/cygrpc.cpython-310-darwin.so' (no such file)
The following problem: on 3.9 python everything works, but when upgrading to 3.10, the following problem an import error occurs
Are there any solutions?
Reacted by Daniel Szczyrba, Raja Simon, Jean-Martin Archer, Craig Labenz, qjetha-klick, Sean Chok, Laurens-T, Kenny, Daniel Marcous, Josh Friend and 35 more
Reacted by David Buxton, Thor K. Høgås, Nikolai Røed Kristiansen, Valerii Baianov and Brian Pugh
Activity
lidizheng commentedon Dec 20, 2021
According to the error details, it seems you own a Macbook with M1 chip, we currently don't have the machine to build binary wheels for them. This error is not Python version specific. On the other hand, you can try to emulate x86 architecture:
arch -x86_64 /bin/bash # Then install Python, Python packages, and run the applicationbenesch commentedon Jan 3, 2022
Actually, it is. I similarly am able to install
grpcioon Python 3.9 but not on Python 3.10, just like the issue reporter.I agree that you wouldn't expect this to depend on the Python version, and indeed that gives us a clue as to what the problem is. On Python 3.9,
pip install grpciobuilds from source (and succeeds), while on Python 3.10,pip install grpciodownloads a precompiled wheel... for the wrong architecture. And indeed... grpcio is publishing this wheel: grpcio-1.43.0-cp310-cp310-macosx_10_10_universal2.whl .Note the "universal2", which is incorrectly claiming that the wheel supports both x86_64 and arm64 architectures.
Not having an M1 mac is fine, but please adjust your build process to tag the wheel with x86_64 instead of universal2 so that M1 macs don't incorrectly download the wheel.
davissclark commentedon Jan 3, 2022
Super annoying.
lidizheng commentedon Jan 4, 2022
Thanks for the report. We are using the same build process for macOS wheels right now. And we uses
auditwheelto make sure we are labelling the wheels correctly. It seems this tagging behavior is changed upstream for 3.10.We might need some volunteer here to investigate why
setuptoolsorauditwheelis tagging the wheel asuniversal2.[-]Mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e') [/-][+][Python][macOS] 3.10 wheel is mislabeled as universial2[/+]benesch commentedon Jan 4, 2022
Doesn't auditwheel only work for Linux?
lidizheng commentedon Jan 4, 2022
Whoops, yep, I was wrong about the
auditwheelpart. It's intended for manylinux:grpc/tools/run_tests/artifacts/artifact_targets.py
Line 150 in 7cfd399
gabriel-viviani commentedon Jan 14, 2022
I'm running on the same problem from using mac air m1 and I've tried multiple python versions, including isolating python with miniconda.

Although when I try to use older versions (3.9.9) to install grpcio I only can see:
41 remaining items
gnossen commentedon Jun 17, 2022
1.47.0rc1has been released to PyPi.. This does not yet include native arm64 wheels, but it does remove the erroneousuniversal2labelled wheels. This will allow you to fall back to a from-source build when using an M1 machine without Rosetta. You can consume it withpip install grpcio --pre.If everything goes well, you should see this in
1.47.0in a few days. Meanwhile, I'll be working on getting our CI to produce native arm64 wheels and trueuniversal2artifacts.pietrodn commentedon Jun 17, 2022
I confirm this is solved.
pip install grpcio==1.47.0rc1on my M1 Pro MacBook Pro now downloads the source distribution, and not the broken wheel. Thank you![-][Python][macOS] 3.10 wheel is mislabeled as universial2[/-][+][Python][macOS] 3.10 wheel is mislabeled as universal2[/+]gnossen commentedon Jun 22, 2022
1.47.0is now released to PyPi. This fixes this particular issue. Sorry for the long wait on this. Stay tuned for further work on Mac OS arm64 support.abax1 commentedon Nov 18, 2022
Any updates on the fix to support apple silicon? This is still not working for me.
pietrodn commentedon Nov 18, 2022
@abax1 there is no fix to support Apple Silicon AFAIK. If you're interested I made this unofficial repo with Apple Silicon builds (look in Releases)
wildone commentedon Jun 9, 2023
Had to downgrade to 1.44.0 as current version 1.54.2 does not have a wheel for Bug Sur 11.7.4 (20G1120). I'll upgrade to 11.7.7 see if it will work without building from source.
peggyxia-alj commentedon Sep 25, 2023
Tried on grpc-1.55.1. This issue is still there on Mac M1 chips with Bazel build.
gnossen commentedon Sep 25, 2023
@peggyxia-alj The Bazel build is not universal2 -- the artifacts labelled
universal2on pypi are. However, Bazel is a native local build, so if you build on an arm64 machine, the artifacts should be compatible with arm64.In general, I would not recommend using our Bazel build to produce artifacts to run anywhere but on the machine which did the build.
abasu0713 commentedon Sep 28, 2023
Best response in all of internet related to this issue! Concise. Uses basic understanding of how pip wheels work! It's just elegant! Thank you so much!