linfa
linfa copied to clipboard
Upgrade to ndarray 0.16
- [x]
ndarray 0.16 - [x]
linfa-llinalg 0.2 - [x]
narray-linalg 0.17 - [x]
ndarray-stats 0.6 - [x]
ndarray-rand 0.15 - [x]
ndarray-csv 0.5 - [x]
sprs 0.11 - [x]
approx 0.5 - [ ]
argmin > 0.10.0 - [ ]
argmin-math > 0.4.0 - [x]
criterion 0.5 - [x]
statrs 0.18 - [x]
thiserror 2.0
Codecov Report
:x: Patch coverage is 39.02439% with 25 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 35.95%. Comparing base (77457b2) to head (493732f).
:warning: Report is 1 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #371 +/- ##
==========================================
- Coverage 36.36% 35.95% -0.41%
==========================================
Files 101 100 -1
Lines 6553 6549 -4
==========================================
- Hits 2383 2355 -28
- Misses 4170 4194 +24
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Is anything blocking this other than the release of a new version of argmin that supports ndarray 0.16?
Is anything blocking this other than the release of a new version of argmin that supports ndarray 0.16?
No. The PR is currently tested against argmin master. AFAIK, argmin's maintainer will release a new version in a few weeks.
Fantastic! Thanks for the quick response :)
Any update on that PR ?
Any update on that PR ?
Nope... Still waiting for argmin new release.
So, when will it be released? Today is August 3.
- argmin
Seems to still blocked by the fact that there are no new argmin release...
Since this is a foundational library, it might make sense to use a range of versions such as version= ">=0.15, <=0.16" in order to provide better compatibility. For me, linfa is a secondary dependency via egobox and I would like to avoid any future clashes with other crates that use slightly different versions.
@jonaspleyer, Beside the fact the code should then be compatible/tested with various versions of ndarray, I am not sure that such spec solves the problem. As stated here for PyO3/rust-numpy, I am afraid you will need to pin the version of ndarray anyway.
@jonaspleyer, Beside the fact the code should then be compatible/tested with various versions of
ndarray, I am not sure that such spec solves the problem. As stated here forPyO3/rust-numpy, I am afraid you will need to pin the version ofndarrayanyway.
Well ... this problem should be solved by a 1.0 release of ndarray. This would mean that we can rely on new versions being compatible. For now, we are stuck in an uncomfortable intermediate state where we can not be sure that 0.17 will be compatible with 0.16 for instance. However, a 1.0 release is not close as far as I can tell.
Both ways which we have discussed have their advantages and challenges. I can understand that you are hesitant to simply allow arbitrary ranges of versions. For me, as a user who relies on many packages that either use ndarray or re-export it themselves, the flexibility would be a great relief. I do not mind pinning the version number but I would like to be able to combine multiple packages with as little ease as possible.
- argmin
Seems to still blocked by the fact that there are no new argmin release...
A new argmin release is out: https://github.com/argmin-rs/argmin/releases/tag/argmin-v0.11.0
Apologies for blocking this, I unfortunately wasn't able to release earlier.