MAINT: update minimal NumPy version

[tupui]

Description

Since the minimal version of Python is 3.6 and NumPy is 1.16.5, you could update minimal SciPy to 1.5.4. SciPy 1.2.3 is quite old now and was the last to be fully compatible with Python 2.

https://scipy.github.io/devdocs/dev/toolchain.html#numpy

[jni]

@tupui Thanks for contributing! But we use NEP-29 as a guide for how long to keep our minimal dependencies. This means we support SciPy versions released 24 months ago, which works out to 1.2.0. In May we can switch to 1.3.0. Try:

$ pip install nep29

then

$ nep29 scipy
| version |    date    |
|---------|------------|
|  1.6.0  | 2020-12-31 |
|  1.5.0  | 2020-06-21 |
|  1.4.0  | 2019-12-16 |
|  1.3.0  | 2019-05-17 |
|  1.2.0  | 2018-12-18 |

[tupui]

Thanks @jni for pointing out this module. But then you are closing this a bit fast as NumPy is not correctly set to 1.17.0. And doing this, you would not be compliant with SciPy as we are stating that the maximal for 1.2.x is NumPy 1.16.x.

So if you don't plan a release before May, I would suggest to use SciPy 1.3.x and NumPy 1.17.x.

[jni]

we are stating that the maximal for 1.2.x is NumPy 1.16.x.

But that is something for pip's resolver to work out, not humans. =) I think! Anyway I'll gladly merge a PR updating our minimal NumPy to 1.7.0! pip can then dismiss 1.2 for us until May. =) (It's unclear whether we'll release before that deadline...)

[tupui]

I updated the branch with the NumPy update. (I guess this needs to be re-open in order to see the new commit.)

[grlee77]

Thanks @tupui, I have reopened the issue and modified its title.

I don't think bumping SciPy from 1.2 to 1.3 buys us any new features we need. The two things in newer SciPy I am aware of that will help us here from a code maintenance standpoint are:
1.) SciPy 1.4 will let us use the scipy.fft module unconditionally
2.) SciPy 1.6 will let us always use the new scipy.ndimage features in that release

[hmaarrfk]

@tupui there are a few other places where the numpy version is used. Please review the changes that I pushed. so you can get a good picture of them.

A bump in numpy also requires a review of the TODO.txt knocking out the items in the TODO list.
https://github.com/scikit-image/scikit-image/blob/main/TODO.txt#L85

[tupui]

Thanks @tupui, I have reopened the issue and modified its title.

I don't think bumping SciPy from 1.2 to 1.3 buys us any new features we need. The two things in newer SciPy I am aware of that will help us here from a code maintenance standpoint are:
1.) SciPy 1.4 will let us use the scipy.fft module unconditionally
2.) SciPy 1.6 will let us always use the new scipy.ndimage features in that release

Thanks! On my side, it was more to encourage users not to rely on an old version. Since then we did not just add features but fixed tons of issues.

[tupui]

@tupui there are a few other places where the numpy version is used. Please review the changes that I pushed. so you can get a good picture of them.

Oh ok, sorry I did not see that you defined the dependencies in other places.

A bump in numpy also requires a review of the TODO.txt knocking out the items in the TODO list.
https://github.com/scikit-image/scikit-image/blob/main/TODO.txt#L85

I will remove the warning assertion. Not sure about the rest, also maybe better for another PR?

[tupui]

@hmaarrfk I updated the PR with 2 items from the list. I did not touch the _round_safe so there is still a loop.

[pep8speaks]

Hello @tupui! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2021-04-21 16:48:35 UTC

[grlee77]

I think this instruction was incorrect. The warning did not occur on old NumPy, but does on 1.17+. I pushed a commit to restore the warning, but make it non-optional now.

[grlee77]

Nevermind, this does not actually appear to warn in my local test environment. I cancelled CI here for now and will investigate further...

[grlee77]

Hopefully CI will pass now. It turns out that only some of the parameterized test cases try to clip using NaN values

[tupui]

ah ok! Thanks for working on the PR btw, really cool!

[tupui]

As a side note, since we are having NP >= 1.17 now, I could propose a follow-up PR to update the usage of np.random.RandomState to the recommended np.random.Generator. I did quite some work on SciPy around the topic so I have a good view of the problem and possible solutions.

[hmaarrfk]

As a side note, since we are having NP >= 1.17 now, I could propose a follow-up PR to update the usage of np.random.RandomState to the recommended np.random.Generator. I did quite some work on SciPy around the topic so I have a good view of the problem and possible solutions.

That would be great. Random number usage is always finicky and i think the new api improves on that.

Could you please open a separate issue so we can track progress.

Also, i would like to suggest postponing merging this due to the impending release of 0.18.2.

Since this touches infrastructure, it would make certain infrastructure fixes harder to backport. (Unless we backport this too)

[tupui]

Sure no problem 👌

[jni]

Awesome, thank you @tupui! (and @hmaarrfk and @grlee77!)

[tupui]

If this is not merged in May, I would then bump SciPy here too as to follow this nep29.

[grlee77]

This looks good now. The only failure on CI was a common timeout, so I will go ahead and merge.