-
Notifications
You must be signed in to change notification settings - Fork 661
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
BLD: NumPy 2 compat for wheel builds #4620
Conversation
* Fixes MDAnalysis#4619 * We should build against NumPy `2.0.0` so that we're backwards compatible to NumPy `1.x` while still supporting 2.x series. This is simpler to maintain as well. In theory, should support as far back as NumPy `1.19` if we needed it.
Linter Bot Results:Hi @tylerjereddy! Thanks for making this PR. We linted your code and found the following: Some issues were found with the formatting of your code.
Please have a look at the Please note: The |
some of our Windows deps may also not have NumPy 2 compatible releases yet, need to check on that |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #4620 +/- ##
===========================================
- Coverage 93.63% 93.57% -0.06%
===========================================
Files 171 183 +12
Lines 21225 22304 +1079
Branches 3930 3933 +3
===========================================
+ Hits 19873 20872 +999
- Misses 894 972 +78
- Partials 458 460 +2 ☔ View full report in Codecov by Sentry. |
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.
Thanks @tylerjereddy - just the one question.
I have a suspicion some of our gh actions CI won't be picking this at all since we do a lot of isolation disabling here and there, but if the azure pipelines CI works then it should be good.
# NumPy version. In that case we just let it be a bare NumPy install | ||
"numpy<2.0; python_version>='3.13'", | ||
# numpy requirement for wheel builds for distribution on PyPI - building | ||
# against 2.x yields wheels that are also compatible with numpy 1.x at |
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.
Is the range of compatible 1.x numpy versions with 2.0 published somewhere? I.e. checking if we need to bump the minimum NumPy version anywhere.
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.
This document isn't too bad: https://numpy.org/doc/stable/dev/depending_on_numpy.html#for-downstream-package-authors. I think we may be "ok" on that front.
You can deduce the stability back to 1.25.x
and then to 1.19.x
based on that document. It looks like we have Python 3.10
and NumPy 1.23.2
as our runtime lower bounds, which is pretty close to where SciPy is (3.10
and 1.23.5
respectively) at the moment.
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.
Let me do a quick check of the current CI failures to see if I can make a concrete suggestion for those as well.
* Related to MDAnalysis/mdanalysis#4620. * See discussion above for details, but in short we should build our wheels against NumPy `2.0.0` so that we have binaries that are runtime-compatible with both NumPy 1.x and 2.x series. * Even if "we" don't do a release soon, I believe this may be helpful since we could then point the MDAnalysis CI at this github repo for `pytng` "no binary" build from source with NumPy 2.x, rather than disabling `pytng` testing over there.
For There may be a few other test failures here to check, but the I've adjusted the original comment to not close the matching issue, since this may be a step in the right direction, but we may need to check other deps/things a bit still. |
* Related to MDAnalysis/mdanalysis#4620. * See discussion above for details, but in short we should build our wheels against NumPy `2.0.0` so that we have binaries that are runtime-compatible with both NumPy 1.x and 2.x series. * Even if "we" don't do a release soon, I believe this may be helpful since we could then point the MDAnalysis CI at this github repo for `pytng` "no binary" build from source with NumPy 2.x, rather than disabling `pytng` testing over there.
I restarted the failed Azure jobs to see if the new |
Looking at the logs, in terms of our dependencies, I'd say |
@tylerjereddy sorry I'm going to word this terribly - these are optional dependencies, is there a path you can see here where we stick to 1.x if you need these optional dependencies and 2+ if you don't? I guess in we'd effectively need two packages with different pins? My view is that this doesn't seem like it would work, but I've put all of five minutes of thought into it. |
* Add NumPy 2-related shims aimed at avoiding control flow that hits `RDKit` or `parmed`, until they have releases supporting NumPy 2. This mostly means skipping a bunch of tests that use those packages for now.
Hello @tylerjereddy! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2024-06-22 13:59:40 UTC |
@IAlibay I think the best I can suggest is to skip the related tests/imports for I pushed in a sample commit that seems to allow the testsuite to pass locally with NumPy 2. Looking at the results in CI here, the only test failure is That doesn't mean the MDA team will like this, but I pushed it in so you can take a look. Maybe not too painful? |
O wow thanks a bunch for digging into this @tylerjereddy ! |
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.
Thanks so much @tylerjereddy ! I hope you don't mind I took the liberty of pushing a few commits directly to make sure we can get this merged in asap.
import parmed as pmd | ||
# TODO: remove this guard when parmed has a release | ||
# that supports NumPy 2 | ||
if NumpyVersion(np.__version__) < "2.0.0": |
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 just added this extra guard here since we were doing the same for RDKit.
Thanks @tylerjereddy - going with the merge! |
Related to CI fails when numpy 2.0.0 is installed #4619
We should build against NumPy
2.0.0
so that we're backwards compatible to NumPy1.x
while still supporting 2.x series. This is simpler to maintain as well. In theory, should support as far back as NumPy1.19
if we needed it.PR Checklist
Developers certificate of origin
📚 Documentation preview 📚: https://mdanalysis--4620.org.readthedocs.build/en/4620/