CI: add reference lowest env solution + script to check its evolutions - #19022

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.

Hum, CI is hitting another edge cache around the astropy[all]<->asdf-astropy circular dependency:

creating virtual environment...
installing uv~=0.9.15...
Using CPython 3.14.0 interpreter at: /opt/hostedtoolcache/Python/3.14.0/x64/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version < '3.12'):
  ╰─▶ Because asdf-astropy==0.9.0 depends on your project and only the
      following versions of asdf-astropy are available:
          asdf-astropy<=0.7.0
          asdf-astropy==0.7.1
          asdf-astropy==0.8.0
          asdf-astropy==0.9.0
      we can conclude that asdf-astropy>0.8.0 depends on your project.
      And because asdf-astropy>=0.7.0,<=0.8.0 depends on your project, we can
      conclude that asdf-astropy>=0.7.0 depends on your project.
      And because astropy[all] depends on asdf-astropy>=0.7.0 and your project
      requires astropy[all], we can conclude that your project's requirements
      are unsatisfiable.

      hint: The package `asdf-astropy` depends on the package `astropy` but
      the name is shadowed by your project. Consider changing the name of
      the project.

      hint: While the active Python version is 3.14, the resolution failed for
      other Python versions supported by your project. Consider limiting your
      project's supported Python versions using `requires-python`.

Traceback (most recent call last):
  File "/home/runner/work/astropy/astropy/scripts/check-lowest-resolved-tree.py", line 99, in <module>
    raise SystemExit(main())
                     ^^^^^^
  File "/home/runner/work/astropy/astropy/scripts/check-lowest-resolved-tree.py", line 63, in main
    new_tree = generate_tree(cli_args.debug)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/runner/work/astropy/astropy/scripts/check-lowest-resolved-tree.py", line 28, in generate_tree
    raise AssertionError("call to uv command failed")
AssertionError: call to uv command failed

I don't know why I'm not seeing this locally. Will try to solve this after lunch.

I'm not convinced the error message even makes sense. I don't see why having a dependency that itself depends on the project should make requirement unsatisfiable (it this was true, dependency cycles wouldn't be allowed at all ?). I will take this upstream for now.

reported at astral-sh/uv#16978

update: my mistake. Resolved locally.

Interesting, now I'm getting what looks like a genuine failure that I seemingly cannot reproduce locally.

A, maybe I got it. appnope is special because, it isn't just a (twice) transitive dependency, it's also platform dependent: ipykernel only requires it for platform_system=="Darwin" (i.e., macOS). I do happen to work on two macOS systems, and CI is on ubuntu. It should not make a difference because I'm explicitly requiring a --universal solution, but maybe that's just not enough to guarantee reproducible and cross-platform resolutions. I'll try to switch the os in CI to confirm or refute this working hypothesis first.

Turned out to be a red herring. Instead, the problem was I had a residual, botched uv.lock locally, which uv used instead of re-computing the graph from scratch. Removing this broken lockfile solved the problem: I was able to align my local system with CI, and update the reference solution accordingly.

rebased to resolve a merge conflict

@Cadair, do you think you could have another look at this reasonably soon ?

I finally got RTD green.
@pllim I see your review is still marked as "changes requested", but I think I addressed everything so far. Is there anything I missed ?

Also if you all want to think about ways this could compromise GHA security, now is the time to do it.

I'm not a security expert so evidently this isn't worth much but I cannot forsee how this would create an attack vector. I do try to stay as paranoid as my mental capacity allows though 😄

Thanks for addressing my comments. I think we just waiting on #19022 (review) now from Tom R.

Don't have time to review in detail myself but if there are two approvals that's fine by me