Update to use HDF5 1.10 compatibility mode rather than 1.8 #2320
Conversation
|
I guess it would be a good idea to first release h5py 3.9.1 wheels still based on previous API for their use with Python 3.12 in order not to put too many changes together for people moving to Python 3.12 |
Codecov ReportAll modified lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2320 +/- ##
=======================================
Coverage 89.77% 89.77%
=======================================
Files 17 17
Lines 2377 2377
=======================================
Hits 2134 2134
Misses 243 243 ☔ View full report in Codecov by Sentry. |
|
I'm not too concerned about that - this should be a very minor change for people upgrading. We're already bundling a newer HDF5, this is just about which compatibility version of its API we request at compile time. |
| 'define_macros' : [('H5_USE_110_API', None), | ||
| # The definition should imply the one below, but CI on | ||
| # Ubuntu 20.04 still gets H5Rdereference1 for some reason | ||
| ('H5Rdereference_vers', 2), |
There was a problem hiding this comment.
Really weird, I looked at the libhdf5-dev H5version.h header file from 20.04, and it look fine...
There was a problem hiding this comment.
Yeah, I spent a little while trying to work out what might be causing it, but I couldn't see anything. 😕
There was a problem hiding this comment.
And there's not some apt caching going on, 1.10.4+repack-11ubuntu1 really is the version downloaded according to the CI.
|
I'm going to merge this, as I think it's a logical follow-up to #2313. If we can figure out why the packaged version from Ubuntu needs the extra compile-time definition of |
This follows on from #2313 (requiring HDF5 1.10.4), and mirrors #1542 (moving to the 1.8 API some years ago).
I'm expecting the first commit will fail CI as we get newer versions of some HDF5 C functions; we'll need to adapt to those.