Closed edgarrmondragon closed 10 months ago
Thanks for having a look. Unfortunately, the tags are very much not correct. You've re-introduced the exact problem the comment talked about solving: Most of the wheels lose their universal2
tag and become x86-only, even though that is not the case.
Archive: greenlet-macOS-3.10.whl.zip
inflating: greenlet-3.0.1.dev0-cp310-cp310-macosx_11_0_x86_64.whl
Archive: greenlet-macOS-3.11.whl.zip
inflating: greenlet-3.0.1.dev0-cp311-cp311-macosx_10_9_universal2.whl
Archive: greenlet-macOS-3.12-dev.whl.zip
inflating: greenlet-3.0.1.dev0-cp312-cp312-macosx_10_9_universal2.whl
Archive: greenlet-macOS-3.7.whl.zip
inflating: greenlet-3.0.1.dev0-cp37-cp37m-macosx_11_0_x86_64.whl
Archive: greenlet-macOS-3.8.whl.zip
inflating: greenlet-3.0.1.dev0-cp38-cp38-macosx_11_0_x86_64.whl
Archive: greenlet-macOS-3.9.whl.zip
inflating: greenlet-3.0.1.dev0-cp39-cp39-macosx_11_0_x86_64.whl
@jamadden any idea why the current one can't be installed in Azure Pipelines with MacOS x86?
Poetry throws this; and it works on every other OS:
Unable to find installation candidates for greenlet (3.0.0)
It does seem like there are two MacOS wheels one with cp311-cp311-universal2 and another cp311-universal2-universal2. Not sure if its related to this?
You'll need to look at pip's debug output, because it works fine for me on macOS. Maybe your pip is too old to understand universal2
?
$ uname
Darwin
$ arch -x86_64 /usr/local/bin/python3.11 -c 'import platform; print(platform.machine())'
x86_64
$ arch -x86_64 /usr/local/bin/python3.11 -m venv ./gtest
$ arch -x86_64 ./gtest/bin/python3.11 -c 'import platform; print(platform.machine())'
x86_64
$ arch -x86_64 ./gtest/bin/python3.11 -m pip install --no-cache-dir greenlet
Looking in indexes: https://pypi.org/simple, ...
Collecting greenlet
Downloading greenlet-3.0.0-cp311-cp311-macosx_10_9_universal2.whl (262 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 262.9/262.9 kB 11.2 MB/s eta 0:00:00
Installing collected packages: greenlet
Successfully installed greenlet-3.0.0
$ arch -x86_64 ./gtest/bin/python3.11 -c 'import greenlet; print(greenlet.getcurrent())'
<greenlet.greenlet object at 0x10afc72a0 (otid=0x10afc71f0) current active started main>
@jamadden Thanks for the feedback. So, I think the issue then is that the greenlet-3.0.0-cp3x-universal2-macosx_10_9_universal2.whl
wheels are not installable and I noticed pip is instead installing the greenlet-3.0.0-cp3x-cp3x-macosx_10_9_universal2.whl
wheels.
The problem then is that there's no 3.12 wheel for x86_64, but I don't know if that's expected:
$ http https://pypi.org/pypi/greenlet/json | jq '.urls[].filename' | grep universal
"greenlet-3.0.0-cp310-cp310-macosx_10_9_universal2.whl"
"greenlet-3.0.0-cp310-universal2-macosx_11_0_x86_64.whl"
"greenlet-3.0.0-cp311-cp311-macosx_10_9_universal2.whl"
"greenlet-3.0.0-cp311-universal2-macosx_10_9_universal2.whl"
"greenlet-3.0.0-cp312-universal2-macosx_10_9_universal2.whl"
"greenlet-3.0.0-cp37-universal2-macosx_11_0_x86_64.whl"
"greenlet-3.0.0-cp38-cp38-macosx_11_0_universal2.whl"
"greenlet-3.0.0-cp38-universal2-macosx_11_0_x86_64.whl"
"greenlet-3.0.0-cp39-cp39-macosx_10_9_universal2.whl"
"greenlet-3.0.0-cp39-universal2-macosx_11_0_x86_64.whl"
$ http https://pypi.org/pypi/greenlet/json | jq '.urls[].filename' | grep cp312
"greenlet-3.0.0-cp312-cp312-macosx_13_0_arm64.whl"
"greenlet-3.0.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl"
"greenlet-3.0.0-cp312-cp312-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl"
"greenlet-3.0.0-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl"
"greenlet-3.0.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl"
"greenlet-3.0.0-cp312-cp312-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl"
"greenlet-3.0.0-cp312-cp312-musllinux_1_1_aarch64.whl"
"greenlet-3.0.0-cp312-cp312-musllinux_1_1_x86_64.whl"
"greenlet-3.0.0-cp312-cp312-win_amd64.whl"
"greenlet-3.0.0-cp312-universal2-macosx_10_9_universal2.whl"
This also affects the wheel for 3.7 but probably fewer people will notice since it's EOL anyway.
In CI, you have/had:
wheel tags --remove --abi-tag universal2 dist/*whl
I don't see what this accomplishes. Candidates for the targeted architecture are chosen based on the platform tag, not the ABI tag.
ABI tags look OK now:
Closes #369