Open tedja03 opened 6 months ago
Hey Ted, actually, we did consider this in the beginning. There is one big problem with it that we did not solve yet. That's why we did not follow this till now. Also the user does not need to decide, which version to install. The version that should be installed depends on the hardware so it's not really a decision, it's more about finding out, which one you actually should use. But maybe we should make a little howto on how to find out which to install.
The biggest problem with making a universal2
version is that signing the .app
breaks it for x86_64
. The programs works as long as it's unsigned and as soon as we sign it, we cannot execute it anymore. We tried to solve this together with the PyInstaller developer, but so far we had no success doing so. This is why we chose to make a signed arm64
version and an unsigned x86_64
version. I fear that a universal2
version we might not be able to sign it at all.
Another question we haven't addressed yet is, if all the Python packages and Python itself are actually universal2
, which might also be a prerequisite for this. Python from Python.org is actually universal2
, but we use Python from brew, which is either arm64
or x86_64
. And we need that brew Python since we still use Python3.9 and the last Python3.9 from Python.org is actually bundled with a Tcl/tk that is buggy when used with macOS Sonoma.
So, even if we have solved the problem of codesigning breaking the x86_64
app, we still have these other issues to solve. We still have this on our mind, but right now, it's low priority.
Maybe I can make a simply standalone app that just tells you, which version to install.
Thank you for a swift reply.
The issue with choosing the right version isn't so much mine, but I'd need to make the effort twice. In our organization, all software is distributed via a Self Service app, and for a platform agnostic approach I would have to package both versions and offer them to our users, who in turn would need to evaluate which version to use. Also, with the Intel release not being signed, would also lead to frustration for our users attempting to use the software.
In either case, thank you for your detailed reasoning!
Maybe we should retry to get rid of the codesign issues with the x86_64
version :). PyInstaller has made some huge version jumps and we also made some improvements to our building pipeline. It still breaks after signing, but maybe it's worth putting some work in figuring out the reasons for this :).
Maybe it's also possible to get a universal2
Python via brew. Otherwise, we need to switch to a newer Python, which is on the todo list anyway. Right now we have a dependency that demands Python3.9, but there are already some plans to change this.
EDIT: And sorry, if my first reply was a bit "rough" :).
We might have a use case for this product in our university's setting, but to simplify installs on macOS, please consider building a Universal2 compatible release of noScribe for platform agnostic installs. This way users need not decide on getting an Intel or Apple Silicon release when downloading and installing the product. Also, such a release should be able to be signed without much additional work being needed.
Resources: https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary