The linux_musl.yml file was supposed to be the place for examining musl, it just so happened to be built/installed through a wheel. I still think it makes sense to keep a musl linux run in this file, but we probably don't need to send it through a wheel first. We may find out at a later stage that we want to amend some options for such a test run.

What pain points do the full/fast runs tend to highlight? We should probably run full on numpy-releases (that gets triggered less), so we can probably run fast in the wheels here, and save some full runs for builds that don't go through wheel building.

What pain points do the full/fast runs tend to highlight?

I just had a look at what's decorated with mark.slow, and it's not that much - mostly f2py tests, I/O tests, some other compile tests, and static typing tests (which won't run by default anyway). So the extra value of running them on more then a handful of platforms is pretty low.

I still think it makes sense to keep a musl linux run in this file,

I really don't think it adds any value. It made a lot of sense when we did not run wheel build jobs on PRs, but when we run a musllinux x86-64 and aarch64 wheel build job already, the extra job is 100% duplicate.

Other jobs that can go, for the same reason, are:

• the Windows x86-64 and arm64 ones that build with scipy-openblas64 in windows.yml
• the plain Linux one on ubuntu-22.04-arm in linux.yml

If we remove all those, that still leaves us with four extra jobs after this PR, which seems acceptable for the win of testing wheel builds by default.

Still TBD: how exactly do we deal with some remaining overlap between files in the numpy and numpy-release repos?

Still thinking about this. Less duplication is good for maintainability. We need to have at least some files in this repo so we can do wheel builds. We don't need the licensing related stuff here, because we're not distributing wheels from this repo anymore, and there's a benefit to removing it (e.g., no license checkers will notice LGPL etc. in this repo and raise flags by default).

The main things that leaves are:

1. cibw_before_build.sh, cibw_test_command.sh and repair_windows.sh
2. the pyproject.toml cibuildwheel config
3. requirements files

I'm inclined to say for (1) that we avoid duplication and use the files in this repo from numpy-release. For (2) the configs are slightly different (e.g., pyodide is added), but could be reused. For (3) it's best kept separate with a check on no mismatches probably, and ensuring the numpy-release ones are minimal; the ones in this repo are very messy with many unnecessary build and test dependencies added.