-
Notifications
You must be signed in to change notification settings - Fork 38
Provide PyOxidizer binaries #109
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
base: main
Are you sure you want to change the base?
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #109 +/- ##
=======================================
Coverage 44.86% 44.86%
=======================================
Files 26 26
Lines 3535 3535
=======================================
Hits 1586 1586
Misses 1949 1949
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
In the meanwhile, I updated the CI from the original PR in one of my repos and were successful in creating binaries: acquire-binaries. I'm mostly interested in the I hope this helps and is okay with you. |
|
After discussions with both internal stakeholders and external users, I noticed a clear consensus; providing pre-built Acquire binaries for download is a major improvement that significantly lowers the barrier to entry. For many users, especially those who just want to experiment with or start using Acquire, this is a game-changer. Building standalone binaries locally remains a non-trivial and often frustrating task. This PR directly addresses that pain point, making Acquire immediately more accessible and usable to a much broader audience. Regarding the suggestion of looking at the build mechanism: while build process optimization is important, the immediate priority should be on availability and usability. The value of having ready-to-use binaries far outweighs the need for a cleaner or more modular build setup at this stage in my opinion. |
|
If I remember correctly, this will not statically link the vcruntime when building Windows executables. Might be worth mentioning when you release this. But do double check yourself. |
This PR adds CI for building PyOxidizer binaries for Windows, macOS, Linux (GNU) and Linux (musl).
The Linux musl build currently depends on a forked PyOxidizer (https://github.com/fox-it/PyOxidizer/tree/esxi-compatibility) because of indygreg/PyOxidizer#725. The fork also includes a workaround for ESXi.
The Linux GNU build is built in a
manylinux2014container to ensure an old libc version for compatibility.The macOS build combines a x86_64 and aarch64 binary into a single universal2 binary for compatibility on both Intel and Apple Silicon Macs.
A separate list of dependencies is currently maintained in
pyoxidizer.bzlbecause there are no appropriate dependency bundles available in acquire right now.miniois included for uploading to cloud storage, but unfortunatelypycryptodomeis not yet included. It should be possible to include it but I couldn't get it working across all OS variants right now, so that could be a future improvement. The way to go here is likely a filesystem fallback on an accompaniedlibdirectory, but for some reason this broke the embeddedmsgpack. PyOxidizer should also be able to recompile an extension into itself but I did not look into this yet.The
pyoxidizer.bzlfile also includes comments explaining how to build manually, as well as how you could modify the embedded configuration.Ideally we add these binaries as files into the releases, but I wasn't sure what the desired CI trigger would be for that, so I've put it on tags for now. For this reason, the PyOxidizer also currently downloads the latest stable
acquirefrom PyPI instead of copying from the local source repository.