Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Universal2 compatible release for platform agnostic installs on macOS #59

Open
tedja03 opened this issue May 22, 2024 · 3 comments
Open

Comments

@tedja03
Copy link

tedja03 commented May 22, 2024

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

@gernophil
Copy link
Collaborator

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.

@tedja03
Copy link
Author

tedja03 commented May 22, 2024

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!

@gernophil
Copy link
Collaborator

gernophil commented May 22, 2024

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" :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants