build for universal2, not separate arm64/x64

[glyph]

Applications that might want to bundle appscript will almost certainly want to be multi-architecture as we are mid-transition to apple silicon; building separate wheels creates artifacts that are architecture-specific and thus will not work in a universal2 application.

I discovered this because I created a virtualenv at the command line, then used nteract (sadly still an x86_64 legacy application) which could not import the new appscript wheels from its kernel.

[fzumstein]

@glyph can't we just add universal wheels instead of replacing them? From what I understand, it's only really a thing for building apps (as you do), pip will always prefer the platform-specific build.

[glyph]

The particular context where I'm experiencing the error right now is not actually an app build: there are a number of contexts where one might have one venv for multiple architectures. Consider an app that is mostly AS native, but has a component that needs to be run as a subprocess to load a legacy x86_64 module. Why would you want to ship architecture-specific wheels, though? With universal2, at the cost of a tiny amount of additional disk space, you avoid a whole slew of compatibility problems where the module won't load.

Also, app builds are generally built out of venvs installed with pip (this is how py2app works, and as far as I understand it, how briefcase works as well.

[fzumstein]

As pypa/cibuildwheel#1333 shows, there are contracting opinions out there. I stuck to the recommendation on cibuildwheel docs:

Generally speaking, because Pip 20.3 is required for the universal2 wheel, most packages should provide both x86_64 and one of universal2/arm64 wheels for now. When Pip 20.3+ is common on macOS, then it might be possible to ship only the universal2 wheel.

Also, I was looking at how other projects handle it. Popular ones like psutil, asyncpg, pydantic, numpy, etc. upload separate wheels (no universal2 wheels). The only project I could find with universal2 wheels (but in addition to x86 and arm86) wheels was mypy.

Anyhow, for appscript, bundle is size is a no-issue as they are super small, but I'd still go with both x86_64 and universal2 instead of just universal2. What do you think?

[glyph]

Anyhow, for appscript, bundle is size is a no-issue as they are super small, but I'd still go with both x86_64 and universal2 instead of just universal2. What do you think?

This is interesting. To make this recommendation I looked at my local cache, which has a ton of universal2 wheels, even for these projects that (as you say) ship different ones, and I'm not quite sure why. The projects I specifically look to to do this stuff well, cryptography and pyobjc (specifically for macOS) seem to be shipping x86_64 and universal2 as you suggest, and that seems to give me the universal2 wheels I want on the version of pip I use, so that seems like a good plan as far as I'm concerned.

[glyph]

I've added x86_64 back to the arch list in the PR just to make this easier :)

[fzumstein]

thanks!

[glyph]

Thank you for keeping this super handy package alive and maintained!

[fzumstein]

All credit goes to @hhas