Only install binary packages on the second install pass.

[freakboy3742]

More edge cases for macOS universal binary builds; this time, revealed by CI on Python-support-testbed.

lru-dict only publishes x86_64 macOS wheels. When CI for Python-support-testbed is executed on x86_64, this results in an attempt to install a wheel for ARM64, which falls back to a source install, which then fails because the source install builds an x86_64 wheel.

The CI build fails on 3.8-3.10. It succeeds on 3.11 because the Python installed in CI is configured to produce universal wheels on compilation.

CI for Python-support-testbed also fails for cffi on Python3.8, for the same reason.

This PR adds the --only-binary :all: option for secondary "other" arch install pass. This will cause the macOS build to fail if you're installing on x86-64 hardware, because there's no ARM64 or universal wheel available. This will require any project using lru-dict, cffi, or any other package without ARM64 binary wheels to provide those wheels.

--only-binary :all is a risky option to turn on for the first pass, because there are packages that only provide source wheels. This PR only enables --only-binary on the second pass, which is by definition only installing binary wheels for packages that didn't provide a universal wheel on the first pass.

To provide an exit hatch for apps that don't provide wheels, this PR also addresses #1482, adding the ability to make apps single-platform by setting universal_build=false in pyproject.toml. This requires an update to the Xcode template (beeware/briefcase-macOS-Xcode-template#27), and is assisted by (but does not require) a change to the base Briefcase template (beeware/briefcase-template#78). No change is needed to the macOS-app template; the stub binary is installed, and then stripped as part of the template unrolling process.

This will also require a PR to Python-support-testbed to provide the missing macOS wheels. If we land this PR, we can re-run CI on the main branch of Python-support-testbed to confirm that this fix works (i.e., the build will fail, but with an error about missing packages, rather than an error about binary merging); then a PR on that repo can add the missing wheels to get the CI passing again.

Fixes #1482
Refs beeware/briefcase-template#78
Refs beeware/briefcase-macOS-Xcode-template#27

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

This will cause the macOS build to fail if you're installing on x86-64 hardware, because there's no ARM64 or universal wheel available. This will require any project using lru-dict, cffi, or any other package without ARM64 binary wheels to provide those wheels.

That could be a pretty big inconvenience, especially for a beginner, or a package that isn't easy to build. So I think this indicates that we need #1482 now after all. And when a universal build fails, we should show a message explaining how to do a single-platform build instead.

[freakboy3742]

This will cause the macOS build to fail if you're installing on x86-64 hardware, because there's no ARM64 or universal wheel available. This will require any project using lru-dict, cffi, or any other package without ARM64 binary wheels to provide those wheels.

That could be a pretty big inconvenience, especially for a beginner, or a package that isn't easy to build. So I think this indicates that we need #1482 now after all. And when a universal build fails, we should show a message explaining how to do a single-platform build instead.

Agreed. I'll add that into this PR before submitting for re-review.