Updates to support iOS dynamic binary modules #33
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
freakboy3742
force-pushed
the
ios-dylib-binaries
branch
4 times, most recently
from
55bcb70
to
f5e2630
Compare
freakboy3742
force-pushed
the
ios-dylib-binaries
branch
from
f5e2630
to
2205fdd
Compare
freakboy3742
force-pushed
the
ios-dylib-binaries
branch
from
5c9a6f8
to
6ccc595
Compare
mhsmith
reviewed
Sep 6, 2023
mhsmith
approved these changes
Sep 7, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supporting binary modules on iOS requires some additional checks, and some configuration tweaks for the support test suite. These tests are currently passing with the existing support package; they must continue to do so with the new dylib-based support package. There should be no other changes required at a project level to make iOS support work.
The patch includes some tweaks for Linux packaging, because the move to Python-standalone was causing tests to fail, and we had no test of Linux system packaging.
As part of those changes, this PR disables AppImage tests as part of CI. This is, frankly, because I have officially run out of patience with AppImage.
Historically, we needed to test AppImage builds to verify that the BeeWare-provided Linux support package worked as advertised. However, with the move to Python-standalone, that's no longer a requirement; we can assume that Python-standalone has done release testing.
On top of that, AppImage builds for this project take over an hour (assuming you can get the configuration working, which... isn't easy), because they involve compiling Numpy and Pandas from source (because AppImage precompiled wheel handling is messed up).
Flatpak also uses Python-standalone, but can use wheels, so it's a much faster test, and are just as effective at confirming that the support package exposes the necessary binary modules.
When combined with the fact that AppImage has all sorts of issues with packaging WebKit, can't run simple GTK binaries without raising all sorts of weird warnings, and System packaging is now the default for Briefcase, the extent to which I am willing to put up with AppImage's 💩 has reached a new nadir.
Refs beeware/Python-Apple-support#176
PR Checklist: