MNT: add pins for pypy39 - #78

https://github.com/matplotlib/matplotlib/actions/runs/5755280099/job/15603253348#step:28:480

Ah, sorry you got hit by this. We removed the distinction between PyPy and CPython for >=3.9 in #74, though admittedly @rgommers was doubtful.

The reason I was quite convinced that we could get away with it, is that we've had a fully passing test suite for PyPy 3.8 & 3.9 starting from numpy 1.19 in conda-forge.

Not sure what errors you're hitting - are you expecting a wheel? In any case, if this causes problems I have no problem to revert that part (ef83f2f; will need some adjustments because testing got more thorough).

I did not read the error message super carefully, I suspect what is going on is 1.19 does not pin back setuptools enough and so there is a build failure when trying to build from source.

For Matplotlib we are going to move to requiring numpy 1.25+ as 1.25 supports all of the Pythons Matplotlib supports so it is moot on our side.

It also looks like it may be a window specific problem as I can np1.19.3 to install from the sdist with cpython3.9.

I do not have a pypy39 version around that is easy to test with (pypy310 fails for other reasons) and I don't have a windows machine set up to test on.

This is the correct fix - numpy 1.25.0 is the first version with wheels for pypy39. There's no need to investigate the from-source build failures I think.

There is an issue with the tests here though. Would you have time to fix those @tacaswell? Then I think this can be merged and a new release cut to solve the problem?

If we're back to fully distinguishing CPython & PyPy, I guess we should also re-add the line

numpy; python_version>='3.10' and platform_python_implementation=='PyPy'

at the very end that was also removed by ef83f2f

I guess we should also re-add the line

I don't think so because we had another issue with Matplotlib where the un-constrained numpy ended up with mpl wheels that did not work for a user who had built an older version of numpy from source on pypy.

I don't think so because we had another issue with Matplotlib where the un-constrained numpy ended up with mpl wheels that did not work for a user who had built an older version of numpy from source on pypy.

That can't really happen anymore with numpy >= 1.25 exporting an old API I think. And it's not clear that pypy3.10 works with that old a numpy version, so we should revert to the old situation.

Also got bit by this issue.

I copied the approach from SciPy to get a build working, but it's less than ideal for several reasons. But it might get others unstuck until this is resolved:

    "oldest-supported-numpy; platform_python_implementation != 'PyPy'",
    "numpy; platform_python_implementation=='PyPy'",

Sorry this got delayed - in it goes now. Wil get a release up with this.