Pin SciPy to >=1.7.3,<1.8.0

[michaelosthege]

Also aligns the SciPy version pins across the testing environments for different Python versions.

See tracking issue #5448.

[canyon289]

Rerunning failed jobs as failure was due to env setup flakiness not code changes

[ricardoV94]

Why the so restrictive lower version?

We use >1.4.1 in v4

[michaelosthege]

There are shape problems and at least locally they went away with 1.7.3.
There were shape problems with 1.5.1 and at least locally they went away with 1.7.3, while I had numpy==1.22.2.

But the env creation doesn't work in all jobs, so there are also problems with NumPy.

The pytest workflow on this branch runs with Python 3.7, required numpy=1.15 and had conflics in env setup ❌
The arviz workflow on this branch runs with Python 3.8, required numpy>=1.15 and ran with numpy==1.22.2 ✔
The windows workflow on this branch runs with Python 3.9, required numpy>=1.15 and ran with numpy==1.21.5 ✔

Our CI envs have different pins for the numpy versions, but I don't understand why we pinned numpy=1.15 only for Python 3.7.
I'll try scipy>1.4.1,<1.8.0 and numpy>=1.15,<1.22.2 for all.

[michaelosthege]

That one failing test (https://github.com/pymc-devs/pymc/runs/5085570253?check_suite_focus=true#step:7:491) isn't just flaky and needs to be fixed before merging. There's no use in having a broken CI on the v3 branch.

[burnpanck]

Why do you pin upper limits to versions in the dependency specification? Please do not do that just for the benefit of uniform versions in CI.

Upper version pinning should only be done when there is a known incompatibility, until compatibility has been re-established. If the dependency uses any sane version numbering system (and both numpy and scipy do!), then minor version number increases should be API backward compatible. Therefore, the expectation should be that minor version increases should be compatible. If they aren't, that's a bug on either end, which should be fixed (and a temporary solution may be a pin on the upper version). But unless there is, upper versions should not be pinned (except potentially before the next major version).

If you just want uniform versions in CI, explicitly select those versions in the CI environments. While the CI might test for an exact specific patch version such as numpy 1.22.1, that's still no reason to pin <1.22.2. It's not like the CI is testing every single patch version between 1.15 and 1.22.1. If Testing 1.22.1 does not give you the confidence that pymc3 will work on 1.22.2, why does testing 1.15 give you confidence that it works on 1.16.1?

[michaelosthege]

@burnpanck this upper version pin was because of a known incompatibility and has since been removed after the incompatibility with SciPy 1.8.0 was fixed.

See #5448 for details.

We try to keep our CI environments free of exact pins and let mamba resolve which versions to use exacly.
But sometimes (like happened here) there are good reasons to temporarily pin upper versions.

[burnpanck]

Ah, I hadn't found any reference to an issue with numpy. On a fresh install on my machine that pin was still active, which led me to jump to conclusions too quickly - sorry for that. I didn't realise I was installing an old version with 3.11.5, as I hadn't taken note of the name change with the move to v4.

Maybe it would make sense to at some point release an explicitly dead version 3.x once that branch is not being maintained anymore, so that downstream dependencies who did not take note of the name change either will fail loudly.