-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MNT: add pins for pypy39 #78
Conversation
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 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
at the very end that was also removed by ef83f2f |
Co-authored-by: h-vetinari <[email protected]>
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm personally okay to leave things as is, even though I think it's a bit of a large gap to put pypy3.9 at numpy 1.25, and leave pypy3.10 at numpy 1.21.
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. |
Got bit by this in Matplotlib CI where it was selecting 1.19.3 for pypy39.