-
-
Notifications
You must be signed in to change notification settings - Fork 11.7k
CI: add check for numpy-release version of scipy-openblas #30166
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
base: main
Are you sure you want to change the base?
Conversation
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.
Nice. A few comments on the new function. At some point we should rename ci_requirements.txt and ci32_requirements.txt and remove non-openblas content, could be in a separate PR.
| v32_rel, v64_rel = parse_reqs(reqfile) | ||
|
|
||
| def compare_versions(v_rel, v_thisrepo, bits): | ||
| if not v64_rel >= v64_thisrepo: |
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.
| if not v64_rel >= v64_thisrepo: | |
| if not v_rel >= v_thisrepo: |
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.
Oops, good catch
| v32 = get_version(line) | ||
| if "scipy-openblas64" in line: | ||
| v64 = get_version(line) | ||
| return v32, v64 |
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.
Might be nice to check and raise a nicer error if v32 or v64 are None. On the other hand, the NumPy repo has both (the unfortunately named) ci_requirements.txt and ci32_requirements.txt. Shouldn't check_requirements check both?
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 considered handling / special-casing the 32-bit only file, but it didn't seem necessary - it already has a very explicit comment "keep in sync with ci_requirements.txt" and I didn't see that ever going wrong, so that's not the type of thing we typically also check in CI.
Might be nice to check and raise a nicer error if
v32orv64are None.
Agreed, that could, will update.
| the first 3 version components, so 0.3.30.0.7 gets translated to 0.3.30 when reading | ||
| it back out from `scipy.show_config()`. | ||
| 2. Check requirements files in the main numpy repo and compare with the numpy-release | ||
| repo. Goal is to ensure that `numpy-release` is not behind. |
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.
Would it be better for the check to be done in numpy/numpy-release instead. That triggers less then the jobs here. It could be done as a smoke test off the bat, on which all other jobs depend.
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 don't think so, for two reasons:
- It doesn't give any signal before CI actually fails on unrelated PRs, because updates go to this repo first.
- In this repo the check is quite cheap to run once; in the other repo we don't have any suitable jobs that run just once, we only have sdist and wheel build jobs.
This ensures that the
scipy-openblas32|64version pinned in thenumpy-releaserepo isn't falling behind the one in this repo. Implemented as discussed in numpy/numpy-release#21 and numpy/numpy-release#6.