TST: require matplotlib binaries in devdeps so that nightlies take priority over pre-releases without wheels - #15284

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?

I'm not well versed in tox; the only way I found to pass force binaries was through a constraint file, but it works. Remaining failures are out of scope for this PR and have to do with NEP 18 function being deprecated in NumPy 2.0.

I'm confused why that would fix it, as we release wheels for our RC.

We don't typically merge the release branch (with its tag) back into main until the final release, and that is what triggers main to bump versions (which then is the wheels we upload to nightlies).

I think what you might actually want is --force-reinstall added to this line as I think it is actually prior to this line that it is getting the rc from pypi as -i is the form that should only look in the one index.

I'm confused why that would fix it, as we release wheels for our RC.

Indeed, but 3.8.0rc1 doesn't have cp312 wheels. My patch wouldn't work (but also would n'y need to, at first) if there was a second RC with wheels for Python 3.12

I agree that forcing reinstall would be more robust, I'm just not sure how to configure that as I'm new to tox.

This RC period is how long? I am not sure if this effort is worth all the time already put into it if the problem is going away on its own within 2 weeks or so.

Though I do wonder why mpldev directive differs from devdeps. @astrofrog or @saimn , do you remember why?

The mpldev config was just for the image tests so we could test with just Matplotlib dev and not also have Numpy dev etc but to be honest I don't think that distinction is really needed anymore and we could probably switch the image test to use devdeps too.

I also don't think this PR is really needed - it's not the end of the world if for a couple of weeks we test against RC instead of true developer versions - it's not ideal but also not critical.

@astrofrog , no, I mean why the mpldev install command is different from the matplotlib dev install command in devdeps.

@pllim 'historical reasons' 😄 - feel free to change

I haven't followed closely but from what I can tell problems appear to be fixed on main ? any way, feel free to close this !

Well, the problem didn't really get solved but now the CI is pulling both matplotlib rc and numpy 1.26 rc (so we're not plagued by numpy 2.0.dev for now).

gotcha. Then I suppose it doesn't hurt either to keep this one around in case you want to merge it after all, and if it's still not merged when matplotlib 3.8 comes out there'll be no cost to closing it.

Sure. I did put a "Close?" label on it this morning, so the bot would close it in 7 days unless it gets a friend to watch the VHS tape.

oooooh, spooky 👻

Ah looks like the timer is longer than a week as PR, so I closed this manually as it is no longer needed. Thanks anyway!