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.

👋 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?

Looks like most builds are indeed broken, except for musllinux and sdist. Will look into it.

I think the only reason musllinux is spared is that it just skips the test step.

possibly relevant excerpt from the changelog:

[discussion about the test cwd change and how to use to come!]

I'll keep an eye out for this, it might reveal why our test command broke.

Following advice I found at numpy/numpy#29007, setting PYTHONSAFEPATH=1 in the test env looked like the solution to our problem. In order to test future behavior more accurately, I included pypa/cibuildwheel#2388, which is supposed to land in cibw 3.0.0 (final), as far as I understand. However, the problem persists:

  + arch -x86_64 /bin/sh -c 'pytest -p no:warnings --astropy-header -m "not hypothesis" -k "not test_data_out_of_range and not test_set_locale and not TestQuantityTyping" --pyargs astropy'
  ImportError while loading conftest '/Users/runner/work/astropy/astropy/astropy/conftest.py'.
  _pytest.pathlib.ImportPathMismatchError: ('astropy.conftest', '/private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/cibw-run-1yflvs1h/cp311-macosx_x86_64/venv-test-x86_64/lib/python3.11/site-packages/astropy/conftest.py', PosixPath('/Users/runner/work/astropy/astropy/astropy/conftest.py'))

at this point, I'd rather ping @henryiii in case I'm just missing something obvious. Any hint, Henry ?

Let me check into why it's not working for numpy first, maybe that will explain this too. :)

FYI, you don't need to run CI, uvx cibuildwheel==3.0.0b1 --only cp313-manylinux_x86_64 locally is the same thing (edit: assuming the config is in pyproject.toml or some other toml file you can pass in).

If this works (it basically works like 2.x, so it should), I'd recommend trying test-sources, too. For numpy I used something like test-sources = ["pyproject.toml", "pytest.ini", "tools"], and for boost-histogram I used test-sources = ["pyproject.toml", "tests"]. If you use test-sources, you can remove placeholders (if you have any). That will be required for iOS (and probably Android whenever they land) builds.

what do you mean by placeholder, is this context ?

That's {project} or similar. For tests that are not in the wheel, they were required; you might not have any (I don't see one quickly looking in the file).

FYI, test-sources has to have at least one file, since we don't differentiate an empty environment variable from an unset one (and the TOML config follows suit). Though you can just copy something like a readme in (pyproject.toml is usually good).

That's {project} or similar.

Thanks ! I don't think we use these so we should be good.

For tests that are not in the wheel, they were required; you might not have any (I don't see one quickly looking in the file).

indeed, we don't have any such tests.

Trying out with test-sources = ["pyproject.toml"] now !

Do you need that top level conftest.py too?

NumPy 2.3.0 also bumps to the newer manylinux, so that should be fine. It looks like you don't use anything from 2_28 (at least on aarch64), so auditwheel is adding the previous tags too. I am not sure there are CentOS 7 era aarch64 OSs around to even catch if this is was making a mistake. :) The order of the auditwheel tags has been changed to better align with the standard, but sadly that was breaking validation on PyPI for a bit (pypa/gh-action-pypi-publish#365), I think it's sorted out now.

awesome, then undrafting this now. Thank you for your continued support through this upgrade !

Thanks for your help in testing cibuildwheel 3.0! :)

trying to add nightly-only cp314 wheels here since this isn't merged yet. I expect that builds may fail on some platform and not on others (manylinux is relatively safe)

failures on windows are real, but likely non-issues for us. I'll report this over my next slot, and I'll probably split this PR in two parts.

cp314 nightlies are now split into their own PR #18336

If the only controversial part about this is the possibly-unwanted release note, I'm happy to drop it, but either way it should be trivial to fix after the fact.
Let me try to ping @astrofrog and @saimn again just in case.

Yes, glibc 2.28 was released in 2018, so we are effectively dropping support for Linux versions released from 2014 to 2018 (which is still pretty conservative). Note that we currently still get manylinux_2_17 tags from the repair stage, which means our wheels are actually still compatible with glibc 2.17, released in 2012, we just cannot guarantee that it'll still work in the future.

Should I add this level of detail to the release note ?

I didn't read all comments but numpy switched to manylinux_2_28 recently IIRC (https://github.com/mayeut/pep600_compliance).

The NumPy 2.3.0 release continues the work to improve free threaded
Python support and annotations together with the usual set of bug fixes.
It is unusual in the number of expired deprecations, code
modernizations, and style cleanups. The latter may not be visible to
users, but is important for code maintenance over the long term. Note
that we have also upgraded from manylinux2014 to manylinux_2_28.

hum, with #18374 merged yesterday, now all that's left in this PR is the release note. I'll force-update the branch to resolve merge conflicts, but if the release note isn't desired then we should close without merge.

Actually, since #18374 was also backported, we our options are

• move the note to 7.1.1
• revert the backport Backport PR #18374 on branch v7.1.x (Bump OpenAstronomy/github-actions-workflows from 1.16.0 to 2.1.0 in /.github/workflows in the actions group) #18377
• close this without merge