Description
Issue №2434 opened by Carlosted at 2021-01-06 15:51:44
Environment:
- Operating system : Mac OS Big Sur 11.1
- Python version : 3.9.1
- SDL version : 2.0.14
- PyGame version : 2.0.1
- Relevant hardware : Apple silicon Mac
Current behavior:
When I run python3 -m pygame.examples.aliens, I get: Sorry, extended image module required
Possible solution:
When I use python 3.9.0 I don't get this error, is this because PyGame is not compatible with this version of python yet?
PyGame installation:
I installed pygame with pip3 isntall pygme.
I also tried python3 -m pip install -U pygame --user and got the same output.
Terminal output:
pygame 2.0.1 (SDL 2.0.14, Python 3.9.1)
Hello from the pygame community. https://www.pygame.org/contribute.html
Sorry, extended image module required
Thanks for the help!
Comments
# # ankith26 commented at 2021-01-06 16:13:57
Somehow the pip installed pygame was not built with SDL_image support.
Sounds like another Big Sur/Apple silicon pip wheels issue
# # ghost commented at 2021-01-06 16:23:48
But I wonder if it was even installed with a wheel?
@Carlosted I have a few questions for you if you don't mind..
- When you run pip install pygame, is it installing from the already compiled version in a wheel, or is it compiling pygame?
- Is it different when you use a different python version?
- Are you using the official python installer? Is it the "experimental" universal2 installer for the 3.9.1 version? I know this it the first to officially support the new architecture.
Thanks!
# # Carlosted commented at 2021-01-06 16:25:12
I used brew list --formula | grep sdl and these are all the SDL packages I have:
- sdl
- sdl2
- sdl2_net
- sdl_gfx
- sdl_image
- sdl_mixer
- sdl_ttf
I hope this can help in some way.
# # ankith26 commented at 2021-01-06 16:43:20
If you already have the sdl dependencies. Then installing pygame from source might be the best option in your case.
Hopefully the next version of pygame can ship with those new Mac wheels, so that other new users don’t face much issues
# # Carlosted commented at 2021-01-06 16:54:32
@galexandreg
- When I install it, I looks like it uses a wheel and I don't see any compiling happening,
Collecting pygame
Downloading pygame-2.0.1.tar.gz (5.5 MB)
|████████████████████████████████| 5.5 MB 2.1 MB/s
Building wheels for collected packages: pygame
Building wheel for pygame (setup.py) ... done
Created wheel for pygame: filename=pygame-2.0.1-cp39-cp39-macosx_11_0_arm64.whl size=2540343 sha256=3b71ecaacfcb9ba3acb5a448d731839f975a27388903ee71e70ae25994cd9440
Stored in directory: /private/var/folders/mk/3j58h8y53yx6gwfgx4xp36880000gn/T/pip-ephem-wheel-cache-0ofv5c44/wheels/24/92/8c/c50d0a63cd21148dc95b7ca7f0ad2bf9e573a8eb93ebc273f8
Successfully built pygame
Installing collected packages: pygame
Successfully installed pygame-2.0.1
- When I use python 3.9.0, It also builds it with a wheel (At least I think it does)
Defaulting to user installation because normal site-packages is not writeable
Collecting pygame
Using cached pygame-2.0.1.tar.gz (5.5 MB)
Building wheels for collected packages: pygame
Building wheel for pygame (setup.py) ... done
Created wheel for pygame: filename=pygame-2.0.1-cp38-cp38-macosx_10_14_arm64.whl size=3348693 sha256=a7f9531e30ab35ca585f3cc40be691ebe0b8a662db17ab1014c522250ac606a3
Stored in directory: /Users/charles/Library/Caches/pip/wheels/e3/30/5a/3740aa0df17eb778676161372bb7b2a180b2b5e65efb5fa3d8
Successfully built pygame
Installing collected packages: pygame
Successfully installed pygame-2.0.1
The only thing I noticed that was different was it defaulted to user installation.
- And for the python installer, I used brew to install python so I'm not sure about the architecture.
Thanks!
# # ankith26 commented at 2021-01-06 17:16:27
I see that in both cases, it’s compiling from source. See how it’s downloading the tar.gz source file and not any wheel. Of course, it’s later building the wheel from the source on your system, so that it can do the install
# # Carlosted commented at 2021-01-06 17:36:05
@ankith26 Does that mean that I'm building it from source? I'm a beginner to this type of stuff.
# # MyreMylar commented at 2021-01-06 19:49:01
You can see the difference in your posted built wheels there:
For the first one:
cp39-macosx_11_0_arm64.whl
That's building a CPython Python 3.9 wheel from source on the macos_11_0_arm64 platform.
I believe mac builds usually will grab earlier macos versions from pypi if they are available, but I believe changing the architecture to arm has confused pip. From what I understand intel code should still work on the arm macs. In this case the mac wheel [available on pypi](https://pypi.org/project/pygame/# files) it should use is pygame-2.0.1-cp39-cp39-macosx_10_9_intel.whl but clearly it isn't here.
Your second build is building a CPython, Python 3.8 wheel this time for the macosx_10_14_arm64 platform, which I'm guessing is caused by having a different version of pip here that doesn't know that big sur was renamed to OSX 11.
The easiest solution for your 3.9 problems may be to manually download the intel chipset wheel here rename the file to:
pygame-2.0.1-cp39-cp39-macosx_10_9_arm64.whl
and then do a:
pip install pygame-2.0.1-cp39-cp39-macosx_10_9_arm64.whl
in the directory that the wheel file is in. See if that works. You could also try updating pip? I expect eventually pygame will have native arm64 versions of pygame for the new chipset macs but it might be a while.
# # Carlosted commented at 2021-01-06 21:15:42
@MyreMylar I get this error when trying to install it with the file:
ERROR: pygame-2.0.1-cp39-cp39-macosx_10_9_arm64.whl is not a supported wheel on this platform.
I think I will continue to use Python 3.9.0 until better compatibility with apple silicon chip
# # Carlosted commented at 2021-01-10 19:26:36
So if I'm understanding correctly, there is currently no fix to this issue because this is due to pip not working properly with apple silicon?
# # MyreMylar commented at 2021-01-10 20:21:24
Seems like there are lots of issues with the new macs not running intel code as smoothly as promised in the marketing. I see issues being reported with tensorflow, numpy and others over the past month or so.
It looks like some related patches have gone in to the projects on the pypa GitHub repo, whether this will all eventually work itself out or not so the intel wheels will actually work on Arm macs or not, I do not know. I expect native wheels for arm macs are going to be the long term solution, which will likely take an unspecified 'while'.
In conclusion, the underlying problem is that the new Arm-based macs don't flawlessly run intel code in all cases as was advertised. From what I've seen the successful python workarounds so far have found a complicated way to build a native Arm wheel for mac arm architecture, but it's likely to take some time for most open source projects, and the multi-platform build tools they rely on, to setup new build process to account for multiple mac targets.
At least I think that's what is going on.
# # Carlosted commented at 2021-01-10 21:15:49
Thanks for the answer @MyreMylar. One last question, should I close this issue or leave it open (I'm very new Github)?
# # astraindev commented at 2021-06-14 04:33:38
Hi, I'm having the exact same issue. The difference is that, on my system, everything is compiled to arm64, not x86_64. Here are my versions:
macOS Big Sur 11.4
Python 3.9.5
pkg-config 0.29.2_3
sdl2 2.0.14_1
sdl2_gfx 1.0.4
sdl2_image 2.0.5
sdl2_mixer 2.0.4_1
sdl2_net 2.0.1
sdl2_ttf 2.0.15
xquartz 2.8.1
pip 21.1.2
pygame 2.0.1
setuptools 57.0.0
venvdotapp 19.7.1
wheel 0.36.2
All but xquartz is arm64. Of course, xquartz is a Universal binary. I've tried compiling it in a virtual environment, not in a virtual environment, from the macOS command line, and from the xterm command line in XQuartz. I've also tried with and without wheel. Of course, I only use venvdotapp within the virtual environment.
So this isn't just an Intel issue.
Running python3 -m pygame.tests gives the following error:
loading pygame.tests.video_test
Traceback (most recent call last):
File "/opt/homebrew/Cellar/python@3.9/3.9.5/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/opt/homebrew/Cellar/python@3.9/3.9.5/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/Users/geek/src/pygame/venv/lib/python3.9/site-packages/pygame/tests/__main__.py", line 144, in <module>
run_and_exit(*args, **kwds)
File "/Users/geek/src/pygame/venv/lib/python3.9/site-packages/pygame/tests/test_utils/run_tests.py", line 352, in run_and_exit
total, fails = run(*args, **kwargs)
File "/Users/geek/src/pygame/venv/lib/python3.9/site-packages/pygame/tests/test_utils/run_tests.py", line 309, in run
raise AssertionError(
AssertionError: Something went wrong in the Test Machinery:
total: 1484 != untrusty_total: 1483
# # ChrisChou-freeman commented at 2021-07-29 11:09:09
same issue
# # PAIN-BARHAM commented at 2021-08-23 19:29:41
Same issue for me on raspberry Pi 4 desktop OS.
# # lachieggg commented at 2021-08-25 00:10:29
Same issue on Big Sur with the M1 Macbook Air.