TST: add a CI job for Python's optimized mode - #17472

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?

hum the error doesn't look at all like what I'm seeing locally and it makes me wonder whether tox itself supports optimized mode (locally I run pytest directly).

I confirm that running PYTHONOPTIMIZE=1 tox -e py312-test locally, I get the same obscure crash in tox than in CI:

...
RuntimeError: config set has been marked final and cannot be extended

I don't know wether that's a bug in tox or elsewhere in the stack but rather than deciphering it I'm going to go with a dead simple, known-good approach for now: just run pytest directly.

sight... there's actually an open upstream issue for tox: tox-dev/tox#3006
The problem with running pytest directly is that it's so different than the rest of our CI that it wouldn't meet our ideal of portability, so I guess I will spend some time trying to fix tox (though not too long).

Alright I think the tox rabbit hole goes way to deep for this to be a reasonable use of my time. Back to a simple (albeit less portable) solution.

there we go ! at least now the errors we see are actually ours !

rebased now that all (known) errors were solved 🤞🏻

Looks like the 29 remaining failures are all about functions that rely on the presence of docstrings, and those can't possibly work in these conditions, so I'll probably need to (conditionally) skip the failing tests. Will give it a go tomorrow.

with my latest batch (#17571, #17572 and #17573), we should be almost there. The only test that's still failing locally lives in a .rst file so I'm not sure it can be skipped only conditionally.

Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then.

In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary.

If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock.

If you believe I commented on this pull request incorrectly, please report this here.

tox-dev/tox#3006 was closed, let's try to revive this

Hi humans 👋 - this pull request hasn't had any new commits for approximately 8 months. I plan to close this in a month if the pull request doesn't have any new commits by then.

In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary.

If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock.

If you believe I commented on this pull request incorrectly, please report this here.