-
|
In our own We were able to fix it by upgrading to 2025.1.1, but it seems strange that the build can just break because pycuda doesn't pin a specific version of NumPy and tried to use 2.3.x automatically. Is this something that can be fixed so that specific versions in specific environments continue to function properly? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Thanks for the question. I find that while pinning works fantastically at the level of an application (i.e. a piece of software with no inbound dependency edges), it does not work well for libraries. Imagine a piece of software depending on two libraries that rigorously pin numpy. There is no guarantee that they will pin to the same version. If they do not, a likely-spurious incompatibility results. If you don't mean strict pinning, but rather upper-bounding the version to known-compatible numpy: I simply don't have the bandwidth. Numpy releases occur frequently, and I maintain tens of packages. If I had to roll a release of all of them on every numpy point release, that would be all I'm doing all day. Plus numpy breaks backward compatibility very infrequently, usually with plenty of warning via deprecation. |
Beta Was this translation helpful? Give feedback.
Thanks for the question. I find that while pinning works fantastically at the level of an application (i.e. a piece of software with no inbound dependency edges), it does not work well for libraries. Imagine a piece of software depending on two libraries that rigorously pin numpy. There is no guarantee that they will pin to the same version. If they do not, a likely-spurious incompatibility results.
If you don't mean strict pinning, but rather upper-bounding the version to known-compatible numpy: I simply don't have the bandwidth. Numpy releases occur frequently, and I maintain tens of packages. If I had to roll a release of all of them on every numpy point release, that would be all I'm …