Remove use of platform-site for other-arch macOS wheel installs.

[freakboy3742]

A follow up on #2155.

macOS was previously using a platform-site to allow for the installation of 'other-arch' binary wheel installations (i.e., installing x86_64 wheels when running on arm64 when a universal2 wheel isn't available). With the platform-site being replaced with platform-config, this gives us an opportunity to remove the use of the platform-site hack on macOS, using native pip --platform handling instead.

This forces the use of binary wheels on macOS - but that's broadly advisable anyway, and avoids having to handle pip's error messages when a local wheel compilation fails.

Also includes a tweak to the Apple input filters to catch a change in log preamble output that iOS started generating with (AFIACT) Xcode 16.

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

[freakboy3742]

@mhsmith This has some overlap with #2162, in that this PR adds a new platform quirk, and that PR moves the location of platform quirks to the common macOS folder. As a stop-gap measure, I've added the platform quirk for this PR directly to the base macOS file, so it's an easier merge.

This change is a blocker on landing the updated Python 3.13 support package, which is needed to submit the cibuildwheel iOS patch.

[rmartin16]

fwiw, a list of packages on PyPI serving a lot of sdists (published feb 2024): https://discuss.python.org/t/358-most-popular-python-packages-have-wheels/43558/11

The list isn't perfect for this because it includes packages with macOS wheels but still have high sdists downloads. However, pysftp, as an example, I don't think would be usable after this change.

Note: please ignore if I'm interpreting "forces the use of binary wheels on macOS" incorrectly.

[freakboy3742]

fwiw, a list of packages on PyPI serving a lot of sdists (published feb 2024): https://discuss.python.org/t/358-most-popular-python-packages-have-wheels/43558/11

The list isn't perfect for this because it includes packages with macOS wheels but still have high sdists downloads. However, pysftp, as an example, I don't think would be usable after this change.

That's correct - it wouldn't be. However, pip wheel pysftp --no-deps produces a py3-none-any wheel. There is no reason the maintainers shouldn't be publishing a wheel, and the fix for Briefcase users is fairly straightforward in the meantime.

I haven't checked all the packages mentioned on that thread, but many of them (future, pyyaml) now have wheels (many of them py3-none-any wheels).

I only found two that were potentially concerning.

psycopg2 only provides wheels for Windows. However, the install message also explicitly calls out psycopg2-binary as the package you probably want, so the problem doesn't exist in practice.

mysqlclient does the same. The maintainer is on the thread you've linked explaining why there's no wheels (essentially Maria/MySQL compatibility)... but saying they'd consider adding wheels. (With my opinionated DB hat on - I almost consider anything that discourages MySQL usage to be a net good in the world 😝 )

The remaining ones that don't have wheels (pyspark, docopt, ...) produces a py3-none-any wheel from pip wheel, same as pystftp. I can't think of any good reason that they don't publish a wheel, other than not being aware that they should.

I only found one (pycrypto) that doesn't produce a py3-none-any wheel - but it produces a universal wheel from pip wheel pycrypto --no-deps. However, the package hasn't been updated in over 12 years - if you're using that package for cryptography at this point, you've got much bigger problems. I suspect it's an example of a package that it high on the download list because of the name, not because it's actually used anywhere.

I'm sure there are others - but at the end of the day, I'm comfortable to use what limited influence BeeWare/Briefcase has as a project to encourage laggards to add add wheels to their release procedures. There's very little argument for not producing wheels, and plenty of arguments why they should be actively encouraged.

[mhsmith]

That's not really true; it's a limitation in Briefcase.

[freakboy3742]

I'll stand by this statement. It's not possible to tell purely from a tarball whether a package will produce a binary or non-binary wheel, or to establish anything about the build environments that are supported by the project. That's an inherent limitation in source tarballs as a distribution format for Python artefacts.

[mhsmith]

This forces the use of binary wheels on macOS

I don't follow why this is necessary. This PR changes the way in which the "other" architecture is installed, but that was already using "--only-binary", ":all:". Why do we need to use it on the "current" architecture as well?

[freakboy3742]

This forces the use of binary wheels on macOS

I don't follow why this is necessary. This PR changes the way in which the "other" architecture is installed, but that was already using "--only-binary", ":all:". Why do we need to use it on the "current" architecture as well?

For consistency. If you have one user building on x86_64, and one on ARM64, you can get different results depending on which is the host platform and exactly which binary wheels are available, because only the "off" platform is enforcing a "binary only" limitation.

[freakboy3742]

@mhsmith As discussed in person, I've added an explanatory comment for why we're using --only-binary even though it doesn't seem strictly necessary.