Wrong architecture for 22.10.0 macosx wheel

[lecardozo]

Describe the bug

I've just recently installed the latest version of Black (22.10.0) on a Python 3.10.5 environment, Mac OSX Monterey 12.5 and got the following error when trying to run

➜  black
Traceback (most recent call last):
  File "/Users/me/.pyenv/versions/testing-black/bin/black", line 5, in <module>
    from black import patched_main
ImportError: dlopen(/Users/me/.pyenv/versions/3.10.5/envs/testing-black/lib/python3.10/site-packages/black/__init__.cpython-310-darwin.so, 0x0002): tried: '/Users/me/.pyenv/versions/3.10.5/envs/testing-black/lib/python3.10/site-packages/black/__init__.cpython-310-darwin.so' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64h)))

After investigating the compiled file, it does seem that it was built for the wrong architecture (arm64 instead of x86_64)

➜ file /Users/me/.pyenv/versions/3.10.5/envs/testing-black/lib/python3.10/site-packages/black/__init__.cpython-310-darwin.so
/Users/me/.pyenv/versions/3.10.5/envs/testing-black/lib/python3.10/site-packages/black/__init__.cpython-310-darwin.so: Mach-O 64-bit bundle arm64

To Reproduce

For example, take this code:

➜ pyenv install python 3.10.5
➜ pyenv virtualenv 3.10.5 testing-black
➜ pyenv activate testing-black
➜ pip install --upgrade pip && pip install black==22.10.0
➜ black

The resulting error should be similar to the one reported above.

To make sure this is no pip mistake (maybe downloading the wrong package?) I've directly downloaded the .whl from Pypi and could reproduce the issue.

Expected behavior

The pre-built wheel should be compiled to the correct architecture, I guess.

Environment

• Black's version: 22.10.0
• OS and Python version: MacOS Monterey 12.5 (x86_64) / Python 3.10.5

Additional context

[ichard26]

Ugh, this is weird. I messed up and this release only shipped with compiled wheels for macOS x86-64 due to a build configuration issue I presume. Looking at your bug report carefully, the wheels actually built fine themselves, but their platform tags are incorrect. All our macOS jobs labelled their wheels with x86_64 and the ARM job finished first which is why the wheel architecture makes no sense. Its "x86_64 but really arm64" wheels made it to PyPI first and caused the upload of the actual x86-64 wheels to fail due to pre-existing distribution filenames.

@JelleZijlstra has deleted the macOS wheels to avoid breakage while we figure this out.

[JelleZijlstra]

Yes, we ended up uploading amd64 wheels labeled as x86_64. I confirmed that after deleting the wheels from PyPI, installing Black 22.10.0 on MacOS x86_64 works fine; it just uses the pre Python wheel.

[ichard26]

I fixed the wheel metadata for all x86_64 and arm64 wheels manually and have uploaded them to PyPI. I have not fixed the universal2 wheels, if people want/need them, please holler.

[JelleZijlstra]

For the 22.12.0 release I skipped the amd64 and universal2 MacOS wheel builds to avoid this issue, but the x86_64 job also failed because apparently it was trying to test the x86_64 wheel on an amd64 machine (https://github.com/psf/black/actions/runs/3658832698/jobs/6184104544). For now we'll have no mypyc-compiled macos wheels.

[cooperlees]

arm64? amd64 is x86_64 …

[JelleZijlstra]

Uh yeah, I always confuse them. a<something>64 :)

[ichard26]

Fixed since 23.1.0.