FIX: building Linux-ARM64 wheels

[TTsangSC]

(See also: #390, #391, #394)

Somewhere between 4.1.3 and 5.0.0 we stopped building linux_aarch64 wheels, perhaps because we bumped the cibuildwheel version in #369 which changed its behavior.

This PR updates pyproject.toml and .github/workflows/tests.yml so that:

• wheels for ARM64 on Linux are again built and tested in CI
• Python 3.14.0rc1 -> 3.14(.0) EDIT done in Codify win arm tests #407

[TTsangSC]

Building ARM wheels on x86 Linux runners is painfully slow (≈ 20 s build time per Python version -> ≈ 3 m). It may be worth considering running build_binpy_wheels on ubuntu-24.04-arm to cut on the emulation overhead.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.06%. Comparing base (60e928f) to head (b0e913f).
⚠️ Report is 33 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #402      +/-   ##
==========================================
+ Coverage   87.56%   89.06%   +1.49%     
==========================================
  Files          18       20       +2     
  Lines        1641     2258     +617     
  Branches      348      474     +126     
==========================================
+ Hits         1437     2011     +574     
- Misses        149      184      +35     
- Partials       55       63       +8     

see 4 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0c769c1...b0e913f. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Erotemic]

It would be really nice to build with the restricted API so we have ABI3 compliant wheels. Then we would only have to build once instead of for each python version. It would also make it easier on users who want to use it on a new python version but in the case where we haven't built the wheels yet. Lastly it would reduce overhead for pypi so they don't have to store so many artifacts. But I'm also not sure how big of a performance hit we would take by doing that.

I need to update my CI template generators for the last script, so I'll try to get to that and include the ubuntu-24.04-arm runner as well.

[TTsangSC]

There may be blockers for an ABI3-compliant implementation:

• Some attributes of PyCodeObject and PyFrameObject are currently accessed via pointer deref. These may be relatively easily rehabilitated with PyObject cast -> PyObject_GetAttrString() with some performance hit.

• What is harder to circumvent though is our use of PyInterpreterState.last_restart_version, which:

  • is needed for detecting whether the sys.monitoring hooks have been changed when the profiler is active, and
  • unfortunately, is not exposed as a public API so far.

  We can maybe dismiss the changing of hooks as an edge case and drop the check (and the subsequent updating of the stored hooks to be restored once the profiler exits),but that would be a feature regression.

[sfc-gh-jmarylander]

Hello @TTsangSC @Erotemic, I was wondering if this was going to be fixed any time soon? My team runs most on ARM and would like it use the newer versions of line-profiler. Let me know if I can help out as well.

[TTsangSC]

As far as I recall we didn't make any code-side change in this PR, just CI/config ones. As such, even if this hasn't gone through yet, it should still be possible to build the package from source...

... the caveat being that more recently merged PRs have touched the C code for 3.14.2 compatibility (e.g. #412, which however causes some undiagnosed problems – see #411), so we'll have to check if everything still works on ARM.

I'll just rebase on HEAD and see what happens.

[TTsangSC]

Huh, now the build sometimes chokes on tests/test_line_profiler.py::test_async_gen_decorator[False]. IIRC I put a conditional pytest.raises() there because there were refcount inconsistencies in Python 3.12+ when the GC isn't explicitly invoked after calling an async function, but apparently they very recently fixed it (see perhaps python/cpython#141112; the fix was pushed to HEAD and backported to 3.14.3 and 3.13.12).

Since we don't have (nor want) fine-grained control of patch versions, we see some "consistently inconsistent" behaviors in the CI jobs:

• Build sdist failed because its Python 3.13 came from actions/setup-python@v5.6.0, which pulled 3.13.12
• ubuntu-latest passed because its Python 3.13 came from pypa/cibuildwheel@v3.1.2, which somehow pulled the older 3.13.5.
• macOS-latest failed because it uses the 3.13.12 that the image ships with.

I will write a small, separate PR to fix the test. @Erotemic

[Erotemic]

Can we just mark the patch versions where the cpython refcount issue is fixed? E.g. adding some condition like

+        vi = sys.version_info
+        xfail_refcount = (
+            (not gc)
+            and (
+                (vi[:2] == (3, 12))
+                or (vi[:2] == (3, 13) and vi.micro < 12)
+                or (vi[:2] == (3, 14) and vi.micro < 3)
+            )
+        )
+        excinfo = None
+        if xfail_refcount:
              ...

[TTsangSC]

Yep basically what I did; just took a nap, will now push it.

[TTsangSC]

Just wrote #421. Sorry for the delay.

[Erotemic]

I merged #421 and rebased this, I'll merge when CI passes here.

[sfc-gh-jmarylander]

Huge! Thanks for the fast turn around :)

Are there any plans to release the linux arm builds for the previously released versions (i.e. 5.0.1 or otherwise)

[Erotemic]

I will make a new 5.0.2 release soonish (which will also include the updated type annotations and removal of pyi clutter). Probably by the weekend.