TST: Include scipy in double run - #17758

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?

@neutrinoceros , do the failures in https://github.com/astropy/astropy/actions/runs/13249455121/job/36983723320?pr=17758 look about right?

For clarity, at the time this PR was opened, these patches are already merged:

• BUG: avoid test pollution in astropy.units #17750
• BUG: avoid test pollution in astropy.modeling #17752

But NOT this one:

• BUG: ensure custom_ucd_coord_meta_mapping context manager performs a (correct) cleanup #17749

A later rerun that makes it green would prove the point, rather than opening this PR after the fact. Hope you don't mind, @neutrinoceros !

absolutely not ! the only reason I didn't do it this way myself is that I didn't figure out the key difference between my local runs and CI (with and without scipy respectively) until I got all fixes up.

@neutrinoceros , do the failures in astropy/astropy/actions/runs/13249455121/job/36983723320?pr=17758 look about right?

hum, these seem like different issues I didn't see locally 🙃
Maybe I actually introduced a new error mode with #17752, so let me try to reproduce this now.

Just tried now. I still didn't get these 4 failures but got 5 different ones:

FAILED astropy/coordinates/tests/test_representation.py::TestCartesianRepresentationWithDifferential::test_represent_as
FAILED astropy/visualization/wcsaxes/tests/test_wcsapi.py::test_coord_type_from_ctype
FAILED astropy/visualization/wcsaxes/tests/test_wcsapi.py::test_custom_coord_type_1d_2d_wcs_overwrite
FAILED docs/coordinates/example_gallery_plot_mars_coordinate_frame.rst::example_gallery_plot_mars_coordinate_frame.rst
FAILED docs/units/combining_and_defining.rst::combining_and_defining.rst

(note that I didn't use parallelism in my local run)

Maybe we need to nail deterministic runs (no parallelism) first and then reintroduce randomization so we at least have a solid foundation ?

Don't have time to revisit, so I re-milestoned this.

Rerunning this on 2025-07-02, I see 2 failures in modeling tests; perhaps previous efforts to un-pollute them were incomplete, or new polluted tests added since we last addressed this issue?

________________ test_fitting_with_initial_values[TRFLSQFitter] ________________
[gw0] linux -- Python 3.11.13 /home/runner/work/astropy/astropy/.tox/py311-test-double/bin/python3

fitter = <astropy.modeling.fitting.TRFLSQFitter object at 0xff174470d650>

    @pytest.mark.skipif(not HAS_SCIPY, reason="requires scipy")
    @pytest.mark.parametrize("fitter", fitters_bounds)
    def test_fitting_with_initial_values(fitter):
        fitter = fitter()
    
        x, y = _fake_gaussian_data()
    
        # Fit the data using a Gaussian with units
        g_init = models.Gaussian1D(amplitude=1.0 * u.mJy, mean=3 * u.cm, stddev=2 * u.mm)
>       g = fitter(g_init, x, y)
            ^^^^^^^^^^^^^^^^^^^^

astropy/modeling/tests/test_quantities_fitting.py:120: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
...
scipy/optimize/_lsq/trf.py:135: in select_step
    p_stride, hits = step_size_to_bound(x, p, lb, ub)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

x = array([ 0.91889636,  6.53513562, 11.59407301]), s = array([nan, nan, nan])
lb = array([          -inf,           -inf, 1.17549435e-38])
ub = array([inf, inf, inf])

    def step_size_to_bound(x, s, lb, ub):
...
>       return min_step, np.equal(steps, min_step) * np.sign(s).astype(int)
                                                     ^^^^^^^^^^^^^^^^^^^^^^
E       RuntimeWarning: invalid value encountered in cast

scipy/optimize/_lsq/common.py:398: RuntimeWarning
________________ test_fitting_with_initial_values[TRFLSQFitter] ________________

(Same as above because this is repeated)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

x = array([ 0.91889636,  6.53513562, 11.59407301]), s = array([nan, nan, nan])
lb = array([          -inf,           -inf, 1.17549435e-38])
ub = array([inf, inf, inf])
...
>       return min_step, np.equal(steps, min_step) * np.sign(s).astype(int)
                                                     ^^^^^^^^^^^^^^^^^^^^^^
E       RuntimeWarning: invalid value encountered in cast

scipy/optimize/_lsq/common.py:398: RuntimeWarning

Well these tests are not new, they already existed last time we ran this check, so I think we can rule out new introductions.
Another source of change is the ecosystem: both scipy and numpy received updates in the interval. We should probably try to pin scipy<1.16 as a quick experiment and see if that "fixes" it.

Great idea, @neutrinoceros ! I pushed a commit out with max pin...

Great ! now we know it's not scipy ! I'm not too hopeful, but before we go for any thing harder, can you try pinning numpy<2.3.0 too ?

No luck, it seems.

numpy==2.2.6
scipy==1.15.3

sigh. If our last run was on feb 10, maybe one last thing to try would be numpy==2.2.2 + scipy==1.15.2

one last thing to try

Sure. Just pushed the commit. Let's see. 🤞

With numpy==2.2.2 and scipy==1.15.2, there is one more model that cause failure, i.e., DogBoxLSQFitter in addition to TRFLSQFitter. 🤪

Oooo it passed!

(squash-merged as requested !)