Codecov Report

❌ Patch coverage is 39.02439% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 35.95%. Comparing base (77457b2) to head (493732f).
⚠️ Report is 1 commits behind head on master.

@@            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     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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 for PyO3/rust-numpy, I am afraid you will need to pin the version of ndarray anyway.

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.