Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

Ok this seems to work fine in main, so if people are happy with it I suggest we merge and then trigger a build with the workflow dispatch.

From the logs, it looks like this is working but what I can't tell is if there is a way to find out for a given wheel what version of Numpy it was built against, to double check.

Can @seberg advise here? 🙏

I think we'd still want to check that the wheels we build work with stable numpy, no? If we did that, I agree #15506 would become superfluous.

From the logs, it looks like this is working but what I can't tell is if there is a way to find out for a given wheel what version of Numpy it was built against, to double check.

Unfortunately, I don't have a great advise here right now. The problem is that you only really see which version is it when you try to import a newer NumPy and it refuses.

If you want something viable today, you can use the NumPy 2.0 nightly wheel and:

import numpy.core._multiarray_umath; numpy.core._multiarray_umath._ARRAY_API = None
import astropy

If it works, you are building with NumPy 2.0, if it fails you are building with NumPy 1.x.

We were discussing whether we could create a tool that does that in a way that it fails to see which version you compiled for, but that needs some hacking and it doesn't exist yet (I am not certain it will actually be easy to do that). I doubt that is super relevant for you, it is mainly something the conda folks would like to test their builds.

EDIT: A note in case someone finds this. The above hack I gave will fail if you use pybind11 because it ships its custom _import_array() logic. There is no reason to worry: pybind11 will certainly be fixed by the time it matters.

Why only do this for scheduled or dispatched events? Shouldn't we be consistent? That is, if I apply "build all wheels" label on a PR, I would expect the same thing to happen, except no wheel upload.

Ok I've now switched it to use the 'dev' build dependencies when doing 'Build all wheels'. Note that at least we will still have a build against the latest stable version in the test_wheel_building job which happens in any case regardless of the label.

I think we'd still want to check that the wheels we build work with stable numpy, no?

The test_wheel_building will always be run in a PR and will test the regular build isolation with stable numpy.

Note that in all cases, the tests are run using the latest stable numpy, not dev numpy.

Ah we need to release https://github.com/OpenAstronomy/github-actions-workflows/releases/tag/untagged-6c0ffc9148fcf9a95fe5 for this to work properly here.

Note that in all cases, the tests are run using the latest stable numpy, not dev numpy.

OK, I now see that that works, indeed, since you just install the wheel with the regular+test dependencies.

Also I think this only solves half our problem. We also need pyerfa dev that is built against numpy-dev, no? xref liberfa/pyerfa#109

Yes I can always try and set up dev wheels of pyerfa, but that's separate as pyerfa isn't a build-time dependency of astropy so not within the scope of this PR.

Not sure what's up w.r.t. your comment on OpenAstronomy so I'll let you merge when you think this is ready.

Yes I can always try and set up dev wheels of pyerfa, but that's separate as pyerfa isn't a build-time dependency of astropy so not within the scope of this PR.

On the astropy side, I guess the alternative would be building erfa in the regular numpy-dev run, right?

@pllim - @Cadair released a new version of the workflows and everything works here now.

Thanks, @astrofrog! Really nice.

@pllim - I have triggered a build of the dev wheels:

https://github.com/astropy/astropy/actions/runs/6632806493

Once that is done we can try what @seberg suggested in #15524 (comment) (I might not be able to get to it for a couple of days so feel free to try it if you like)

@seberg I tried your suggestion with the latest dev wheels which have now been uploaded, and using:

pip install --extra-index-url https://pypi.anaconda.org/astropy/simple astropy --pre --upgrade

but import astropy fails after setting ..._ARRAY_API = None. I'll need to try and see if I can improve the vebosity of the cibuildwheel builds to check what version of numpy it is downloading.

Fix in #15533

@seberg @pllim @mhvk - there are now nightly wheels for pyerfa which can be installed from https://pypi.anaconda.org/liberfa/simple – if I do:

rm -rf test-dev
python -m venv test-dev
source test-dev/bin/activate
pip install --extra-index-url https://pypi.anaconda.org/scientific-python-nightly-wheels/simple numpy --pre
pip install --extra-index-url https://pypi.anaconda.org/liberfa/simple pyerfa --pre
pip install --extra-index-url https://pypi.anaconda.org/astropy/simple astropy --pre
pip freeze
python -c 'import numpy.core._multiarray_umath; numpy.core._multiarray_umath._ARRAY_API = None; import astropy'

there is now no longer an error in the last command! 🎉

Awesome, thanks!

A note in case someone finds this. The above hack I gave will fail if you use pybind11 because it ships its custom _import_array() logic. There is no reason to worry: pybind11 will certainly be fixed by the time it matters.

Thanks so much, @astrofrog!!