BLD: Use NumPy nightly wheels for non-release builds #27204
Conversation
This uses the NumPy nightlies for non-release builds to ensure the matplotlib nightlies uploaded are build against the new NumPy version. These nightlies are not tested, but if they were they should actually still be tested against the release NumPy. This is necessary to allow NumPy to enforce API changes, it does mean that potential C-API breaks in NumPy need quicker follow-up unfortunately (either in NumPy or in matplotlib).
There was a problem hiding this comment.
Thank you for opening your first PR into Matplotlib!
If you have not heard from us in a week or so, please leave a new comment below and that should bring it to our attention. Most of our reviewers are volunteers and sometimes things fall through the cracks.
You can also join us on gitter for real-time discussion.
For details on testing, writing docs, and our review process, please see the developer guide
We strive to be a welcoming and open project. Please follow our Code of Conduct.
Co-authored-by: Thomas A Caswell <tcaswell@gmail.com>
|
I got my self a bit confused about how our nightly uploads to anaconda.org work. To save others the time of reading that workflow, we download the most recent wheel artifacts from a build on We also have a weekly job that runs our main test jobs with the pre releases of numpy and pandas, but we use it for both building and for testing. Rather than opting out of the build isolation, would it make more sense to pass |
You would opt into pre for other dependencies, but yeah, I can try that tomorrow. It should definitely be a bit smaller of a change. |
Once you are living on the edge might as well go all the way 😉 |
| rm -rf {package}/build | ||
| CIBW_BEFORE_BUILD_WINDOWS: >- | ||
| pip install delvewheel numpy>=1.25 && |
There was a problem hiding this comment.
I wasn't sure why the numpy install ahead of time. I tried this a bit (but no artifacts yet) and it works, but I don't see in the log whether the correct numpy got installed.
There was a problem hiding this comment.
I believe this was added when we were having problems with oldest-supported-numpy (and decided to fix them by switching to the np 1.25+ backwards compatible builds)
I think that it is likely we haven't needed it on this line since we switched to meson/pyproject.toml, but it did get changed in #26443.
There was a problem hiding this comment.
but if we are using build isolation the wheel build won't see this numpy instal....
There was a problem hiding this comment.
I thought we have build isolation by default in cibuildwheel, but I am not sure what the default does exactly.
Co-authored-by: Thomas A Caswell <tcaswell@gmail.com>
appears to be the logging we get.... |
|
The logging is unfortunate, but I tried the artifact wheel and it looks wrong. Have to check a bit more careful and think about it (if I got the right one for the first version, that may have been also wrong). |
|
OK, I confirmed that the new wheels were compiled with the NumPy nightlies :). |
This uses the NumPy nightlies for non-release builds to ensure the matplotlib nightlies uploaded are build against the new NumPy version.
These nightlies are not tested, but if they were they should actually still be tested against the release NumPy. This is necessary to allow NumPy to enforce API changes, it does mean that potential C-API breaks in NumPy need quicker follow-up unfortunately (either in NumPy or in matplotlib).
Closes gh-27174
I have tested that it calls with
--no-build-isolationand installs the right NumPy before that. I am not sure that this is the best approach, it is rather tedious to set up all dependencies manually (and I am not a workflow specialist)!For example, I don't really understand the
>-but I removed it because that means that newlines are not included in the'strings', which would otherwise make trouble.