Builds python wheels for linux/aarch64

[merschformann]

Description

Modifies "build-wheels" workflows to also build for linux/aarch64 platform. Due to the lack of a Github runner for this platform, we use QEMU. While this works nicely, we need to split the build step to account for the conditional and the build using QEMU takes 5x as long. 😬

Changes

• Adds QEMU setup step when build matrix is facing aarch64
• Adds conditional build step for aarch64 to explicitly set CIBW_ARCHS_LINUX
  • Ternary unfortunately didn't work, so, I wasn't able to keep it in one step. There is probably another way, but I thought that the less I mingle with the other build targets the better. 😊
• Did above changes for build-wheels-push.yml and build-wheels.yml alike

Notes

I was pinged by @ryanjoneil about wheels for linux/aarch64 (cc @galabovaa ). I had some time to spare tonight, so I just went for it. The approach seems to work nicely for Pyvroom (see their workflow).

Happy to assist with further work related to this.

Thanks again for this awesome project! 🤗

[galabovaa]

Thank you, @merschformann! This is great ☺️ Merging this is master, so it will be included in the next release.

Aiming to make it over the next few days, Julian and I just need to discuss if there is anything else we need to add before we tag it.

Just a note, we usually open PRs to the branch latest, rather than master, to keep master consistent with the latest tagged release.

Thanks again for making this happen so quickly!

[merschformann]

Oh sorry, I didn't know about using latest. My bad. I can change the base branch to latest quickly, if that helps.

And happy to help. Let me know if there is more to do. 😊

[jajhall]

It's not a problem, we can change the base, but there's always the chance that we don't spot it

[merschformann]

Makes sense. Is it possible to change the default branch to latest, or does that mess with other things? (just to mitigate the risk)

[galabovaa]

We’d like master to be stable and consistent with the latest release, and latest to contain our latest changes. Latest gets broken sometimes, as we develop, so it’s best to have master as the general default.

There may be a setting for a default branch just for new PR’s that we have not come across yet, is that what you meant? I just did a quick search but could not find anything obvious

[galabovaa]

For this PR going to master is OK, because it only changes a workflow and not the HiGHS code. I make exceptions occasionally for testing edits, but we make sure to merge master in latest afterwards and ideally it would be a one way communication

[merschformann]

Yeah, that makes sense. I will keep it in mind now.
And yes, I meant changing the default branch in general. That of course has other potential drawbacks, like newcomers checking out a potentially unstable branch.

Anyway, thanks again for your work! Have a great remaining weekend! ❤️