-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Rebuild for PyPy3.8 and PyPy3.9 (1.19 branch) #264
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
…nda-forge-pinning 2022.04.03.14.32.43
@isuruf @jakirkham @beckermr I don't see a reason not to TBH - this PR is passing, it would unblock the migration (there are test failures with 1.22), and it would put |
I don't know if there is a demand for NumPy + PyPy versions other than 1.22, but if it is "cheap" to do so it might be nice. |
Planning to merge this soon-ish. Whether the migration gets adapted is a separate question, but otherwise this has no downsides I can think of. |
Agree with @mattip. If you have a use case for this, let's merge, but if not lets close this PR |
The "usecase" I'm thinking of is to have less variation in numpy host versions for the packages we build. CPython (e.g 3.10) is different because there, old numpy versions are simply not amenable for backporting, but numpy 1.19+ is source-compatible with 3.8/3.9 and so I think we should do it for pypy, given that it's very little effort (which I'm willing to do, at that). |
892bc4d
to
6495a22
Compare
Thanks! |
Checking if we can do 1.19