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?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• 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?

Whatever you do here needs to match the minversions stated in https://github.com/astropy/astropy/blob/main/pyproject.toml . That is the point of oldestdeps. Thanks!

Does it make sense to have a script to control this? I really like to have a single source of truth and we can have a pre-commit action that runs the script which updates tox.ini and other places wherever these min/max bounds are present.

This probably should be folded into #15603 but I would like to test out some CI stuff here :)

Does it make sense to have a script to control this?

Indeed, it does. @WilliamJamieson even wrote a script somewhere, I think. But no one had the time to try it out here. Appreciate you cleaning this up. Thanks!

Also, if you want to push this forward, either here or in another PR, another thing that needs to go with the bump is removing old compatibility code that we no longer needs. Usually we have checks like packagename_LT_x_y scattered in the codebase but even that won't catch everything. @eerovaher has been great catching dead code lately so maybe he has tips on that front.

https://github.com/astropy/astropy/blob/main/astropy/utils/compat/optional_deps.py

Example usage:

Now that #15603 is merged maybe we can look/discuss this? Maybe this requires a APE (maybe not?)

APE on optional dependencies would be overkill, so no need, I think. Yes, we can definitely review this now after a rebase. 😉 Thanks!

Oh nvm... You did rebase, but you changed the job name to py310-test-image-mpl363-cov. I think you also have to update https://github.com/astropy/astropy/tree/main/astropy/tests/figures to match.

And also update https://docs.astropy.org/en/latest/development/testguide.html#image-tests-with-pytest-mpl (oh nvm, you did... I should have looked at the diff first 😅 )

Once the jobs are passing, we can email this PR to astropy-dev , so the community have a chance to support/object to this. I can override branch protection at merge time because of the name change in a required job. Thanks!

Hash might need updating too but if @larrybradley or @astrofrog can actually confirm that the "failures" are nothing to worry about, that would be best.

https://output.circle-artifacts.com/output/job/ee93f8b9-db78-4da2-af69-3786ead368b2/artifacts/0/results/fig_comparison.html

I don't think bumping the version requirements for the sake of bumping the requirements is very helpful. It would be helpful to remove compatibility code for obsolete versions of dependencies. Sometimes such code is difficult to find (if it is not using the packagename_LT_x_y) variables, but at least regarding ipython and pandas the amount of astropy code that uses them is so small that reading through all the relevant code should be feasible.

For the packages in "core Scientific Python" that already follow SPEC 0, there is no harm to adopt their policy in this respect. This would ensure we don't accidentally claim we support a very old version when that is not the case.

For pandas, we currently does not mention a minversion, so we're only really testing against latest stable. By setting a minversion, it is actually an improvement than not at all.

I haven't looked at our code that interfaces with pandas, so it might indeed be the case that setting a version requirement without making any other changes is the right thing to do for that. But for ipython I know that we do have compatibility code (at least) in astropy/utils/console.py. Only increasing the version requirement when our code is still capable of handling older versions does not seem helpful. If the version requirement is increased then the relevant compatibility code should be removed too.

Re: IPython -- Yes, does seem some code clean-up is needed if we want to keep the bump:

I don't see anyone being tied to very old IPython though, so the bump itself isn't controversial to me.

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.

Sorry this went stale and now too many conflicts. I have superseded this with #16820