Skip to content

Conversation

@Schamper
Copy link
Member

@Schamper Schamper commented Nov 17, 2023

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 manylinux2014 container 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.bzl because there are no appropriate dependency bundles available in acquire right now. minio is included for uploading to cloud storage, but unfortunately pycryptodome is 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 accompanied lib directory, but for some reason this broke the embedded msgpack. PyOxidizer should also be able to recompile an extension into itself but I did not look into this yet.

The pyoxidizer.bzl file 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 acquire from PyPI instead of copying from the local source repository.

@codecov
Copy link

codecov bot commented Nov 17, 2023

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 44.86%. Comparing base (5748e82) to head (63b5885).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
acquire/utils.py 60.00% 2 Missing ⚠️
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           
Flag Coverage Δ
unittests 44.86% <60.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@cuhsat
Copy link

cuhsat commented Nov 16, 2024

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 .exe file for my specific use case and added UPX compression to it. As for now, I have only tested it on my machine (TM) and found it working under Windows 10.

I hope this helps and is okay with you.

@joost-j
Copy link
Contributor

joost-j commented Oct 2, 2025

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.

@qmadev
Copy link
Contributor

qmadev commented Oct 2, 2025

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.

@joost-j joost-j requested a review from Miauwkeru October 2, 2025 13:20
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

Successfully merging this pull request may close these issues.

7 participants