[wheel] Add support for manylinux aarch64

[tyler-yankee]

Add a host of aarch64 targets to the Linux wheel build matrix, and teach the builder to distinguish between architectures when assembling the list of targets to build, by only selecting the targets on the currently running arch.

Given Drake's pending removal of official support for Ubuntu Jammy, only add support for Linux aarch64 wheels starting with Python 3.12 (the version of choice on Noble). Additionally, don't support MOSEK for the new wheels, at least for now.

This commit only adds the ability to produce the wheel files. It does not document official support nor update release automation.

---

This change is 

[tyler-yankee]

Trying to test this with a CI image by hand is being held up by git issues when Bazel tries to fetch SNOPT. I may have to bite the bullet and figure out how to set that up, but in the meantime, let's see what CI does.

@drake-jenkins-bot linux-arm-noble-unprovisioned-gcc-wheel-experimental-release please.

[tyler-yankee]

Some fixes where the MOSEK hose wasn't fully shut off.

[tyler-yankee]

@tyler-yankee made 1 comment.
Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers, labeled "do not merge" (waiting on @tyler-yankee).

---

tools/wheel/wheel_builder/linux.py line 65 at r1 (raw file):

    ),
    Target(
        build_platform=Platform("arm64v8/almalinux", "aarch64", "9", "almalinux9"),

ruff would like to split this and the other aarch64 instances below onto multiple lines (too long). I'm generally in support of line-length constraints, but this one...not a fan. It leads to an ugly inconsistency with how the matrix is defined.

[tyler-yankee]

Drake can build a Linux aarch64 wheel! https://drake-jenkins.csail.mit.edu/job/linux-arm-noble-unprovisioned-gcc-wheel-experimental-release/job/PR-24066/3/

-(status: do not merge) -(status: do not review) +a:@mwoehlke-kitware for feature review, please.

@tyler-yankee made 1 comment.
Reviewable status: 1 unresolved discussion, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers, labeled "do not merge" (waiting on @tyler-yankee).

[jwnimmer-tri]

@jwnimmer-tri made 1 comment.
Reviewable status: 2 unresolved discussions, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

---

tools/wheel/wheel_builder/linux.py line 98 at r1 (raw file):

        python_sha="2299dae542d395ce3883aca00d3c910307cd68e0b2f7336098c8e7b7eee9f3e9",  # noqa
    ),
)

BTW Another way to phrase this would be like

targets = {
    "x86_64": (
        Target(...),
        Target(...),
        ...,
    ),
    "aarch64": (
        Target(...),
        Target(...),
        ...,
    ),
}[ARCH]

That way, call sites that use this don't need to filter anything, the constant is always correct without extra work.

[jwnimmer-tri]

@jwnimmer-tri made 1 comment.
Reviewable status: 3 unresolved discussions, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

---

a discussion (no related file):
BTW Maybe not for this PR (though maybe it makes things easier), but I was wondering...

What if we put the mosek yes/no governance into the Target (linux) and PythonTarget (macos) constant definitions? We would flow that information down to where it's needed, instead of replicating if-else logic into multiple places that must all align.

[mwoehlke-kitware]

tools/wheel/wheel_builder/linux.py line 65 at r1 (raw file):

Previously, tyler-yankee (Tyler Yankee) wrote…

ruff would like to split this and the other aarch64 instances below onto multiple lines (too long). I'm generally in support of line-length constraints, but this one...not a fan. It leads to an ugly inconsistency with how the matrix is defined.

Consider promoting 'arch' to a top-level attribute of Target rather than being an attribute of Platform? That will also let the script skip Targets that don't match the host arch.

[tyler-yankee]

@tyler-yankee made 2 comments.
Reviewable status: 3 unresolved discussions, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

---

a discussion (no related file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

BTW Maybe not for this PR (though maybe it makes things easier), but I was wondering...

What if we put the mosek yes/no governance into the Target (linux) and PythonTarget (macos) constant definitions? We would flow that information down to where it's needed, instead of replicating if-else logic into multiple places that must all align.

will defer to @mwoehlke-kitware ...

as I recall there's also a TODO left somewhere about moving some of the MOSEK functionality in the Bash scripts to Bazel.

All of this presumably gets easier with resolution of #23867, because the way we tell the wheel builder that we don't want MOSEK in the wheel directly will be more consistent across platforms. So perhaps hold off until that's done?

---

tools/wheel/wheel_builder/linux.py line 98 at r1 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

BTW Another way to phrase this would be like

targets = {
    "x86_64": (
        Target(...),
        Target(...),
        ...,
    ),
    "aarch64": (
        Target(...),
        Target(...),
        ...,
    ),
}[ARCH]

That way, call sites that use this don't need to filter anything, the constant is always correct without extra work.

ah, I like that guarantee. will fix

[tyler-yankee]

@tyler-yankee resolved 2 discussions.
Reviewable status: 1 unresolved discussion, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

[tyler-yankee]

@drake-jenkins-bot linux-noble-unprovisioned-gcc-wheel-experimental-release please.
@drake-jenkins-bot linux-arm-noble-unprovisioned-gcc-wheel-experimental-release please.

[tyler-yankee]

OK, Linux wheels on both arches are still good as of the current rev.

@tyler-yankee made 2 comments.
Reviewable status: 2 unresolved discussions, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

---

tools/wheel/wheel_builder/linux.py line 92 at r2 (raw file):

        Target(
            build_platform=Platform("arm64v8/almalinux", "9", "almalinux9"),
            # TODO(jwnimmer-tri) Switch testing to 26.04 once it's been released.

nit unfortunately we have line length too long on these comments now...

[mwoehlke-kitware]

@mwoehlke-kitware reviewed 4 files and made 2 comments.
Reviewable status: 3 unresolved discussions, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

---

tools/wheel/wheel_builder/linux.py line 92 at r2 (raw file):

Previously, tyler-yankee (Tyler Yankee) wrote…

nit unfortunately we have line length too long on these comments now...

Eh, wrapping them isn't the end of the world, especially as the wrapping will be consistent.

---

-- commits line 4 at r2:
BTW, this sentence seems out of date?

[tyler-yankee]

@tyler-yankee resolved 2 discussions.
Reviewable status: 1 unresolved discussion, LGTM missing from assignee mwoehlke-kitware, needs platform reviewer assigned, needs at least two assigned reviewers.

[mwoehlke-kitware]

(commit is much better, thanks!)

@mwoehlke-kitware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers.

[mwoehlke-kitware]

Previously, tyler-yankee (Tyler Yankee) wrote…

will defer to @mwoehlke-kitware ...

as I recall there's also a TODO left somewhere about moving some of the MOSEK functionality in the Bash scripts to Bazel.

All of this presumably gets easier with resolution of #23867, because the way we tell the wheel builder that we don't want MOSEK in the wheel directly will be more consistent across platforms. So perhaps hold off until that's done?

Yes, I would think/hope the long term goal is that MOSEK is supported everywhere, or at least depends only on Python version.

[tyler-yankee]

@drake-jenkins-bot mac-arm-sequoia-clang-wheel-experimental-release please.

[tyler-yankee]

+a:@jwnimmer-tri for platform review (Monday), please.

[jwnimmer-tri]

@jwnimmer-tri reviewed 6 files and all commit messages, made 5 comments, and resolved 1 discussion.
Reviewable status: 3 unresolved discussions.

---

a discussion (no related file):

Previously, mwoehlke-kitware (Matthew Woehlke) wrote…

Yes, I would think/hope the long term goal is that MOSEK is supported everywhere, or at least depends only on Python version.

MOSEK will probably always be a special case with bespoke constraints. The #23867 doesn't change the support matrix, only the loader mechanism. There is no plan to add implib support for the aarch64 linux ABI, so the newly-added guards will need to remain for the foreseeable future. The aspiration of supporting more configurations in the future should not affect the question of "should we don't-repeat-yourself on mosek configuration" in the present day.

---

tools/wheel/image/build-wheel.sh line 82 at r3 (raw file):

[ ${PYTHON_MINOR} -ge 15 ] && MOSEK_ENABLED=

# MOSEK is not currently supported for Linux aarch64 wheels.

nit This comment says we're only changing "Linux aarch64" but it is not clear from the code why the "linux" part isn't being checked for here, instead of only the architecture. I suppose it's because arch on Darwin says something other than aarch64 but that's not clear enough from the code and comment.

---

tools/wheel/image/build-wheel.sh line 83 at r3 (raw file):

# MOSEK is not currently supported for Linux aarch64 wheels.
[ "$(arch)" == "aarch64" ] && MOSEK_ENABLED=

BTW This is dead code, right? It seems to me like for the purposes of this script, only Darwin needs to know whether MOSEK is enabled. I can see the case for keeping the dead code here as future protection in case linux starts to care later on, but possibly it would be simplest to revert this part instead of fixing the comment clarity defect noted above?

---

tools/wheel/test/tests/mosek-test.py line 18 at r3 (raw file):

# version number, we should bump this up to match, and also grep tools/wheel
# for other mentions of MOSEK version bounds and fix those as well.
# Additionally, MOSEK is not currently supported for Linux aarch64 wheels.

nit This comment says we're only changing "Linux aarch64" but it is not clear from the code why the "linux" part isn't being checked for here, instead of only the architecture. I suppose it's because platform.machine() on Darwin says something other than aarch64 but that's not clear enough from the code and comment. It's especially important here in the test, because this is the sole cross-check that all of the other flags got set correctly during the build.

[mwoehlke-kitware]

tools/wheel/image/build-wheel.sh line 83 at r3 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

BTW This is dead code, right? It seems to me like for the purposes of this script, only Darwin needs to know whether MOSEK is enabled. I can see the case for keeping the dead code here as future protection in case linux starts to care later on, but possibly it would be simplest to revert this part instead of fixing the comment clarity defect noted above?

Seems like it. Actually, the only reason for MOSEK_ENABLED seems to be the special magic needed on macOS to remove it from the wheel, which should cease to be necessary when we have implib on macOS.

...which makes the question, what is the situation for MOSEK on Linux ARM64? Not supported? Supported via something like the current macOS hack? Not supported until implib has Linux ARM64 support?

[jwnimmer-tri]

@jwnimmer-tri made 1 comment.
Reviewable status: 3 unresolved discussions.

---

tools/wheel/image/build-wheel.sh line 83 at r3 (raw file):

Actually, the only reason for MOSEK_ENABLED seems to be the special magic needed on macOS to remove it from the wheel, which should cease to be necessary when we have implib on macOS.

Nope. This PR is turning off MOSEK on Linux aarch64 wheels.

So yes, MOSEK on aarch64 wheels is "not supported".

[mwoehlke-kitware]

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

MOSEK will probably always be a special case with bespoke constraints. The #23867 doesn't change the support matrix, only the loader mechanism. There is no plan to add implib support for the aarch64 linux ABI, so the newly-added guards will need to remain for the foreseeable future. The aspiration of supporting more configurations in the future should not affect the question of "should we don't-repeat-yourself on mosek configuration" in the present day.

So... this might be incomplete as it's based on changes in this PR, but... places we currently have logic to test if MOSEK is enabled of not:

• setup.py: I think this has to be stand-alone. At best, we could configure this file, but the expression still has to be written as a requirement, which means it must be a single, static string regardless. Maybe we can get to where we have enabled/disabled in a single file, but not a single definition... unless we can change other users to evaluate the requirement condition string.
• build-wheel.sh: I think this script will no longer care once we have implib on macOS.
• build-drake.sh: It would take some work to 'inject' the flag into here (needs to pass through a Docker argument), but might be worthwhile.
• mosek-test.py: Might be worthwhile, but not immediately obvious how to pass a flag into the tests.
• linux.py: Doesn't care right now, but seems like the most likely candidate for where to centralize.

[jwnimmer-tri]

@jwnimmer-tri made 1 comment.
Reviewable status: 3 unresolved discussions.

---

a discussion (no related file):

Previously, mwoehlke-kitware (Matthew Woehlke) wrote…

So... this might be incomplete as it's based on changes in this PR, but... places we currently have logic to test if MOSEK is enabled of not:

• setup.py: I think this has to be stand-alone. At best, we could configure this file, but the expression still has to be written as a requirement, which means it must be a single, static string regardless. Maybe we can get to where we have enabled/disabled in a single file, but not a single definition... unless we can change other users to evaluate the requirement condition string.
• build-wheel.sh: I think this script will no longer care once we have implib on macOS.
• build-drake.sh: It would take some work to 'inject' the flag into here (needs to pass through a Docker argument), but might be worthwhile.
• mosek-test.py: Might be worthwhile, but not immediately obvious how to pass a flag into the tests.
• linux.py: Doesn't care right now, but seems like the most likely candidate for where to centralize.

Yeah. After looking at it more myself, I think the status quo is probably good enough. Adding more plumbing is probably adding complexity without enough gain.

[tyler-yankee]

@tyler-yankee made 1 comment and resolved 3 discussions.
Reviewable status: complete! all discussions resolved, LGTM from assignees jwnimmer-tri(platform),mwoehlke-kitware.

---

tools/wheel/image/build-wheel.sh line 83 at r3 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Actually, the only reason for MOSEK_ENABLED seems to be the special magic needed on macOS to remove it from the wheel, which should cease to be necessary when we have implib on macOS.

Nope. This PR is turning off MOSEK on Linux aarch64 wheels.

So yes, MOSEK on aarch64 wheels is "not supported".

Fair enough, I can revert this change

[jwnimmer-tri]

@jwnimmer-tri reviewed 3 files and all commit messages.
Reviewable status: complete! all discussions resolved, LGTM from assignees jwnimmer-tri(platform),mwoehlke-kitware.