Apple announced yesterday that they will switch the CPU architecture for macOS over the next couple of years. While doing so there will be once again binaries with multiple architectures (x86_64 and arm64 this time).
I’m wondering how to deal with this in the naming of wheels. In the past we’ve introduced custom machine names for these fat binaries (for example “universal” for “i386 and ppc”), but that was before the introduction of explicit support for multiple compatibility tags in the packaging ecosystem.
There seem to be two alternatives:
Add a new custom “machine” type “universal2” for “x86_64 and arm64”. This extends the existing support for fat binaries in macOS and the name matches Apple’s name for the new combination.
Don’t add a new “machine”, but use multiple compatibility tags in wheels that support both architectures.
As usual there are arguments for both sides:
- The first option makes it easier to ensure that you get binaries that support the same set of architectures as the Python binary, which is convenient when you want to collect wheels for use on a set of machines.
- The first option probably requires less invasive changes, the changes to the stdlib are basically an update to a single function (_osx_support.get_platform_osx)
- The second option makes it easier to find binaries that support your particular machine, even if there are no fat binaries yet.
BPO-41090 contains a rough patch implementing the first option.
EDIT: Fixed name of the new architecture from amd64 to arm64; added reference to a BPO-item with a rough patch.