Hatch-mypyc uses the building platform during cross-compilation, not the target platform (_PYTHON_HOST_PLATFORM)

[ichard26]

Hey, so Black uses hatch-mypyc. It's great and we're happy we can finally use modern packaging standards! Unfortunately, it broke our cross-architecture macOS builds. When using CIBW to build universal2 and arm64 wheels for macOS, the wheels end up with the wrong platform tag. For example, here they are labelled to support x86_64, but they're arm64 wheels in reality.

Setuptools labels the wheels correctly. Hatchling only supports inferring the platform tag for the machine the build is taking place on and ignores _PYTHON_HOST_PLATFORM (which CIBW sets during a cross-platform macOS build).

My best guess at how setuptools selects the right platform tag during cross-compilation

• Digging through the setuptools codebase, I'll guess that it uses sysconfig.get_platform() which looks at _PYTHON_HOST_PLATFORM here.

• The wheel name is derived from Wheel.egg_name() which calls distutils.util.get_platform() assuming it isn't any already.

• distutils.util.get_platform() calls distutils.util.get_host_platform()

• distutils.util.get_host_platform() calls sysconfig.get_platform() which as noted, checks _PYTHON_HOST_PLATFORM

Figuring out where the platform tags stored in .dist-info come from isn't nearly as obvious -- I barely know the setuptools codebase

I did not catch this issue while reviewing the original PR so this affected the 22.10.0 release (psf/black#3312). In the interim, I'm fixing the wheel platform tags by hand before publishing them to PyPI. It works, but it isn't ideal 🙂

cc @zsol since he is way more knowledgeable about this kind of stuff than me

[ofek]

related: PyO3/maturin#1289

[ofek]

from @henryiii:

https://github.com/scikit-build/scikit-build-core/blob/e9a6e97a0ae7ffffcb5c3756112b2a59339bb4ef/src/scikit_build_core/builder/builder.py#L51-L55 is how I do it.

ARCHFLAGS is how setuptools targets other arch’s and cibuildwheel and conda set it.