Upgrade ndarray and other deps

[cguentherTUChemnitz]

This is a superset of #386 to provide the missing build environment updates based on the transitive dependency MSRV requirements.

I do not know how to just add the last commit just to the already existing PR without being a maintainer, therefore i just opened this parallel MR containing all the same commits and adding just one commit myself on-top.

best,
Christian

[Dirreke]

Thank you for your work. However, I don't think it will work as there's no tag named 1.67-2020.1 for rust-mkl . I'm not sure if we still need to test this container?

Besides, I’m also not certain if the MSRV policy has been implemented. If it’s permitted to bump MSRV, I could also help finish it.

cc @bluss

[cguentherTUChemnitz]

Does that mean, we have to update the repository of: https://github.com/rust-math/rust-mkl-container/blob/main/.github/workflows/pack.yml

To provide a docker image with the desired rust version? So we potentially wait for the discussion on MSRV to settle for a specified rust version and than go here for an update in the corresponding rust-mkl repository? Or can we do this already in advance independently to MSRV?

[bluss]

Thank you both. @akern40 any thoughts on MSRV? We could make a quick decision to run with a version that's forced by deps here

[bluss]

#390 was almost entirely disjoint from this one, so it went in first. It should make work on this easier.

[akern40]

My two cents on MSRV is that 1) we should have the same MSRV for both ndarray and ndarray-linalg and 2) those should both bump up to at least 1.71, which is what we would need for up-to-date BLAS compatibility. Given that we are low on maintainers and nobody (to my knowledge) has ever complained about an MSRV bump in either repo, I am tempted to say something like "our MSRV will try to accommodate Debian (the paradigm for old rustc compatibility), but we won't conditionally compile if one of our dependencies updates"

[akern40]

Ok it turns out we'd actually need 1.76 to keep up with openblas-src v0.10.10. I'm putting in a PR to at least fix our CI on ndarray by pinning to openblas-src v0.10.9, and I've opened up an issue on openblas to discuss more

[cguentherTUChemnitz]

@Dirreke I rebased to master with the ci-fix and dropped my commit of the non-existing image releases like: ghcr.io/rust-math/rust-mkl:1.67.0-2020.1. Maybe this helps here to retrigger the pipeline.

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.

Project coverage is 86.88%. Comparing base (3e13736) to head (3545492).
Report is 5 commits behind head on master.

Files with missing lines	Patch %	Lines
ndarray-linalg/src/convert.rs	60.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #389      +/-   ##
==========================================
- Coverage   90.11%   86.88%   -3.24%     
==========================================
  Files          77       64      -13     
  Lines        4613     3591    -1022     
==========================================
- Hits         4157     3120    -1037     
- Misses        456      471      +15     

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

[cguentherTUChemnitz]

As far as i understand, did the cargo fmt commit trigger the codecov job. So i dropped just this one commit.

[bluss]

I think we should rustfmt but ignore codecov warnings for this

[cguentherTUChemnitz]

I think we should rustfmt but ignore codecov warnings for this

Can this be ignored, when runned as explicit ci-job, that is failing here? Can a maintainer force a merge, even when the coverage job is red?

[bluss]

Yes, it was done that way in #390 too

[sjackman]

Thank you for merging this PR! Any plans to tag a stable release of ndarray-linalg that includes these dependency updates?