DEP: drop support for Python 3.11, require 3.12+ - #20223

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.

oldestdeps is failing with

ModuleNotFoundError: No module named 'six.moves'

(from cycler via matplotlib)
I don't understand it yet. six is actually installed there, as a declared dependency to cycler

edit: resolved by constraining six >= 0.16.0, which is the oldest version I cannot reproduce this error with.

Still hitting this error, and still getting six==1.9.0 despite the constraint. I'm suspecting a cache invalidation issue with tox, tox-uv, or OpenAstronomy/github-actions-workflows, but nothing conclusive yet.

The cached .tox actually isn't the (only ?) problem. I'm able to reproduce the issue locally without a .tox, and installing with uv directly gives me yet another version of six (1.5.0). That is, despite the resolver's logs clearly seeing my constraint:

DEBUG Adding transitive dependency for python-dateutil==2.7.0: six>=1.5
DEBUG Adding transitive dependency for python-dateutil==2.7.0: six>=0.16.0

This looks like something is broken in uv's resolver itself, but there's an additional source of error in the tox/tox-uv layer. Let's see if I can at least work around it for now by adding a direct requirement on six.

Nevermind, my constraint just contained a typo. The fix was

diff --git a/pyproject.toml b/pyproject.toml
index 7436fe9f2d..c3bfa6efb6 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -829,7 +829,7 @@ required-environments = [
 constraint-dependencies = [
     "asdf>=2.15.1",
     "asdf-coordinates-schemas>=0.2.0",
-    "six>=0.16.0", # for Python 3.12+ compat
+    "six>=1.16.0", # for Python 3.12+ compat

     # via pytest
     # iniconfig 1.0.1 is the first version with proper wheels

This is stable now and ready for formal reviews.
I squashed most of my commits into a single one, with one exception for a commit that turned out not to be entirely necessary but took disproportionate time to figure out and will be needed eventually, so I'm proposing to keep it attached. I could also move it to a separate PR if needed.
For context and posterity, this secondary commit is about adding constraints to indirect dependencies that used to require six but don't anymore. six<0.16 turned out to be incompatible with Python 3.12 which is why I hunted it down, but six is not completely gone from the graph either: html5lib and python-dateutil both still require it as of their latest versions. Furthermore, html5lib is now EOL so it'll just be in this state forever (#14316), and python-dateutil is in a difficult place right now with a huge chunk of the ecosystem relying on it but very little maintenance effort goes to it, so it's unclear wether that will be resolved in the forseeable future:

• six version range too loose — breaks on Python 3.13 dateutil/dateutil#1430
• Python 2 deprecation schedule dateutil/dateutil#653

whoops, I'm only just now seeing an error on double-tests jobs, which I don't immediately get off-hand. Re-drafting for now. Hopefully I'll figure it out tomorrow.

That double-test error surely is due to #20090...
...
...
yes, I confirmed it. I just do not understand how it was possible the tests passed before!

Anyway, the fix is obviously to not cache string to unit parse results if there was a warning; see #20226.

Thanks. No reason to keep this drafted then !