Thanks for your interest in helping. Having someone with actual access to a Apple Silicon device would be great, as I’ve been flying blind so far.
The PySide6 experiment is dead for now, so. Encountered too many issues and instabilities, and config migration would have been a pain. So zas and I decided to abandon this approach and stay with PyQt, which is proven and stable. There had been two main reasons for considering PySide: 1. It’s released together with new Qt releases, so theoretically might be more up to date and 2. they did provide Apple Silicon binaries when PyQt did not yet.
But PyQt now provides Apple Silicon binaries, although with one downside that they only provide partially universal2 binaries. The PyQt6 packages on PyPI consist of two parts: The PyQt6 package, which contains the actual Python modules providing the Qt bindings, and the PyQt6-Qt6, which provides pre-compiled Qt6 binaries.
The PyQt6 package is available for macOS as a single universal2 binary. The PyQt6-Qt6 however has separate packages for arm64 and x86_64. AFAIK this is due to package size limits on PyPI.
I would have liked to provide a single universal package, but that is not a strict requirement. We could as well have two separate packages, one for arm64 and one for x86_64.
Currently there are multiple options to go about providing Apple Silicon support:
- Adapt the build process to build two separate app packages for arm64 and x86_64.
- Instead of using the Qt6 binaries from PyPI compile Qt6 ourselves. This probably also involves rebuilding PyQt6. I really wanted to avoid this overhead, though. Picard’s packaging is already complex enough.
- Use the Qt6 binaries from the PyQt6-Qt6 package, but combine the individual binary files for arm64 and x86_64 into a combined universal2 binary. I haven’t investigated further how feasible this is, the Qt6 packages consist of quite a few individual binaries. But theoretically the structure should be the same in both architectures and some script could combine the two architectures for each file.
If you want to help digging into this and providing a solution you are more then welcome. I personally lack both the time and a machine to properly test on. My current focus will be getting a bugfix release for Picard 2.12 out and then focusing on the new plugin system again, so it would be quite a while until I will get back to macOS packaging.
As rdswift wrote best would be to get in touch in the chat.
If you want some pointers building the Picard app package on macOS is done with PyInstaller. The production is being build with the macos* scripts in picard/scripts/package at master · metabrainz/picard · GitHub . The build is controlled by Gitlab CI with picard/.github/workflows/package-macos.yml at master · metabrainz/picard · GitHub
But for local development and testing when running Picard from the source tree the simple answer is actually that one needs to install pyinstaller with pip and then build the app bundle with pyinstaller --clean picard.spec. That would build the app bundle for the system, architecture, though, no universal binaries.
I had the basic changes for building universal2 packages in the branch at Commits · phw/picard · GitHub . As far as I could tell it worked except for the Qt6 binaries, as discussed above.
