BLD: stop skipping musl wheel builds #26443
Conversation
|
opened scipy/oldest-supported-numpy#78 upstream to oldest-supported-numpy |
pyproject.toml
Outdated
| "oldest-supported-numpy; platform_python_implementation!='PyPy'", | ||
| "numpy>=1.25; platform_python_implementation=='PyPy'", |
There was a problem hiding this comment.
My current understanding is that we should actually just be able to do numpy>=1.25 independent of platform since numpy/numpy#23528
There was a problem hiding this comment.
Is our set of supported Pythons a subset of the versions that numpy supports in 1.25?
There was a problem hiding this comment.
answering my own question: yes
I'll do that too.
There was a problem hiding this comment.
It defaults to going to 1.17, which is perhaps a bit too far back... but also not really a harm in that, unless we actually know we need something newer? (At which point adding a #define can change the version, just not sure where the most sensible place for that define is)
There was a problem hiding this comment.
Specifically, it allows you to put in the C code a line like
#define NPY_TARGET_VERSION NPY_1_22_API_VERSIONTo control the python version. the default is NPY_1_17_API_VERSION
If we use features more recent (and the macro is not defined by e.g. pybind11/cibuildwheel already), we may wish to put the line specify 1.22 somewhere.
There was a problem hiding this comment.
We should do that in a follow-up PR.
If it defaults to an API version older than we actually support then we are sure it will work :)
As of numpy 1.25.0 we no longer need to pin to the oldest supported versions to make wheels work reliably.
tacaswell
force-pushed
the
bld/unskip_musl
branch
from
26f0ced
to
8b6e6b3
Compare
|
Got slightly worried that this change would e.g. install numpy 1.25 over the minimum supported version, but looks like we are good on that front (it is installed with So LGTM |
|
This should also be updated, right? (Maybe a release note as well?)
|
|
I don't think that we need to update any of our docs for this change. We will build with any version of numpy that we support, however because of the way that the pip/wheels ecosystem pushes the responsibility for building re-distributable wheels out to the projects and because wheels do not have enough meta-data to express their (set and build time) ABI dependency on numpy, we have to build the wheels with a version of numpy that will result in binaries that will work with any numpy that a user might have installed. Before numpy 1.25 this was done via the I do non view that as an actual "build requirement" any more than what ever pins fedora / debian / conda / arch / ... set as part of their build systems. That we have to set this here is just an artifact the the pip/wheel ecosystem expects to be able to leak its internal details back into every single project. |
|
Note that the So these pins only actually apply for build-isolation (which is the default) builds, which will be installing a new numpy anyway, so any effect is minimal if present. |
ksunden
added
the
Release critical
|
Marking as release critical because pypy builds are failing on main |
New wheels are generally documented in development API changes for a release. |
I missed we did that 🐑 , pushed docs. |
|
The ARM builds are taking extra long here... perhaps we should remove musl on arm, since that is a bottleneck? Numpy does not supply MUSL arm builds, which explains the length extension on the cross platform builds. |
Co-authored-by: Kyle Sunden <[email protected]>
closes #26438
I think that this is a generically bad idea (see https://pypackaging-native.github.io/meta-topics/user_expectations_wheels/ for longer comments on this), but given the currently low cost of enabling this there is no good reason to not do this.
I opened the PR so later when I say it was a bad idea at least I am to blame for it ;)