Add Windows ARM64 build

[ndabas]

• Add tests for the change. In general, aim for full test coverage at the Python level. Rust tests are optional.
• Add any appropriate documentation.
• Add a summary of changes to the latest section at the top of CHANGELOG.rst. (If it's not there, add it.)
• Add your name to AUTHORS.rst.
• Run just full-check.

As the title says.

The changes look slightly crazy because:

• setup-python (and official CPython) only have binary releases from 3.11 onward.
• maturin expects aarch64 as the architecture while setup-python wants to see arm64.
• There was an existing issue in the release workflow which caused only free-threaded wheels to be built for Windows x86 and x64. This is a known issue. So I have added a separate step to build the free-threaded wheels as per the recommended workaround.

[ndabas]

Also I'm not sure if this change is significant enough for inclusion in AUTHORS, I added that because the PR template said so, but can remove it no problem.

[codspeed-hq]

Merging this PR will improve performance by 11.91%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 25 untouched benchmarks
⏩ 23 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	test_get_import_details	161.3 µs	144.2 µs	+11.91%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ndabas:main (66a5eb6) with main (f4d9ecf)}

Footnotes

1. 23 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[seddonym]

Thanks for your contribution! (You should definitely be listed in the contributors 😄 .)

I'm all for building the Windows ARM64 wheels, but if we're doing that, shouldn't we also be running tests under that architecture in the same way?

[ndabas]

Thank you!

I can add Windows ARM64 to the test job too -- the reason I didn't already is that currently, that job only runs for Ubuntu (x64), macOS (arm64), and Windows (x64) -- but we already build for a whole lot of other architectures (e.g. armv7, arm64, etc. on Linux) and those aren't tested either.

So the simplistic approach might just be to add Windows ARM64 to the test matrix, which will look quite odd IMHO because all of the other architectures will be missing.

The other, better way I think would be to add testing to the end of the wheel build process, so that we can test every wheel that we build.

I'd be happy to do it either way -- what do you think?

[seddonym]

the reason I didn't already is that currently, that job only runs for Ubuntu (x64), macOS (arm64), and Windows (x64) -- but we already build for a whole lot of other architectures (e.g. armv7, arm64, etc. on Linux) and those aren't tested either.

That's a good point. I think aligning all these would be scope creep for this PR, so I've merged it as-is.

From what I understand, given we're using pyo3, cross-architecture issues are less likely, and it could really slow down CI to run under every architecture because some of them may require emulation which is a lot slower. Perhaps it would be worth running tests for each architecture during the release process, but I'll leave that for another day.

Thanks for your contribution!

[seddonym]

I'm now going to test the release workflow manually to check everything builds ok.

[ndabas]

Thank you very much, that workflow worked fine in my fork so hopefully all should be good.

[seddonym]

Yep, looks good. Thanks again!