BLD: build with numpy 2.0.0rc1 (or newer)

[neutrinoceros]

Description

Now that numpy 2.0.0 pre-releases reached ABI statbility, we can start building wheels against it.
This is required (but possibly not sufficient) to close #16167

• By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

[github-actions]

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?
• 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.

[github-actions]

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

[mhvk]

I put the milestone at 6.1, but am wondering about labels. What's-new and a changelog entry both seem reasonable (likely just 16252.other.rst noting that 6.1 will be the first to support numpy 2.0.

I'm actually slightly surprised this all works without pyerfa also going to numpy 2.0rc1 - we certainly need to do that one too...

[neutrinoceros]

I'm actually slightly surprised this all works without pyerfa also going to numpy 2.0rc1

that's because pyerfa isn't a build-time dependency to astropy, so we're already able to compile astropy, but you're right that we need new wheels for pyerfa for astropy to work with numpy 2.0 at runtime. Anyway, I just opened a similar PR on pyerfa

[neutrinoceros]

I also just added a changelog fragment as requested

[pllim]

I wasn't sure what was the agreed plan w.r.t. v6.1 vs numpy 2.0 but usually we don't pin to unstable or pre-release. I will change this to draft for now and defer to @astropy/astropy-project-release-team . Thanks for your help and patience!

[neutrinoceros]

For context see bullet point 4 from numpy/numpy#24300

[astrofrog]

I think we do need to temporarily pin to 2.0.0rc1 in pyproject.toml to release the v6.1 wheels before Numpy 2.0.0 final.

[mhvk]

As for the pyerfa version, I'm not quite sure we should set the minimum version here, or whether it is better to set it in the processes that create the wheels. It is not that astropy requires numpy 2.0 to build; it only requires it if you also want to run on 2.0.

[neutrinoceros]

It is not that astropy requires numpy 2.0 to build; it only requires it if you also want to run on 2.0.

That's correct. However I don't quite get the objection here; build-time dependencies from pyproject.toml are only consumed by pip and will (by default) not affect the runtime environment (following PEP 518, supported since pip 18.0 (2018-07-22)). Not only is this following the existing practice in astropy itself (and elsewhere), it also seems to me this is the simplest course of action, and I'm not sure I see any actual down side:

• packagers are still free to compile against whatever version of numpy they want
• expert users who know about pip's --no-build-isolation would also know to patch pyproject.toml if they needed to.

So, who would this be actually affecting negatively ?

[pllim]

OK thanks for the feedback all. I took it back out of draft. But might want a follow-up issue to pin to numpy stable again when we can.

[neutrinoceros]

@pllim good point. I opened and linked #16257

[saimn]

Yes we need to build wheels with Numpy 2.0 (rc1 currently) to get wheels that are runtime compatible with both Numpy 1.x and 2.0. And every package that has C/Cython extensions using the Numpy C API needs to do the same.
So change looks good to me 👍

[pllim]

Do you want to trigger a dev wheel build now or you ok to wait one day?

Thanks, all!