Managing multiple versions of a dependency

help
#1

Hello,

I am using the ndarray crate in my application which needs the latest version 0.14.0. However I am also using ndarray-csv which seems to want to depend on ndarray=0.13.1 (even though it says ^0.13.1, which I took the caret to mean that it could go to 0.14.0).

In any case my application is now throwing all kinds of errors, sayinig that multiple ndarray versions are likely installed, which is clearly the case. The methods from ndarray-csv are returning a different type than the rest of the application wants in order to use 0.14.0 traits.

How can I resolve this? Can I coerce the ndarray-csv Array type int a v14 array somehow, or is there another way to do this?

Thanks so much!

#2

Cargo considers two versions semver-incompatible whenever they differ at or before the first nonzero component, which in this case is the minor version number: 0.13.1 is only compatible with 0.13.x for other x, not with 0.14.0.

#3

I see, thanks. It actually looks like there is no caret in front of 0.13 anyway. I have cloned ndarray-csv and updated the dependency to 0.14 and all the tests pass, so maybe I'll just use a local build once I figure out how to point cargo to a local path, reading the manual now.

#4

ndarray = "0.13.1" in [dependencies] is the same as ndarray = "^0.13.1". Both mean "any version that's semver-compatible with 0.13.1".

If ndarray-csv works with ndarray v0.14.0 you could submit a pull request bumping the dependency.

1 Like
#5

Good point.

#6

BTW

cargo tree -d

will show you incompatible duplicate versions in your project

#7

Thanks for the tree command, I was using it but didn't know about the -d flag. I have submitted a PR as it does look like v0.14 passes all the tests.

I suppose in cases where you could not upgrade the proper approach would be to make a conversion function that takes the old type and converts to the new type so the rest of the code could use the new type.

1 Like
#8

Seems like this would be impossible difficult in many cases because of private fields.

You might be able to do something using Cargo's support for overriding dependencies here, but I'm not sure.

#9

Well I suppose you are right in a lot of cases. In this case its just an ndarray::Array2 so I would think you could just construct a new array with the old array's data. So if you have enough to call a constructor then I would think this would work.

I am new to rust though (and systems programming in general), so maybe I am missing something or there is a better strategy here?

1 Like
#10

Looking through "Overriding Dependencies" in the reference again, I don't think there's a great solution -- i.e. one that doesn't boil down to forking ndarray-csv to update its ndarray dependency -- without some involvement of the crate maintainer. If the manifest says ndarray = "0.13" then Cargo simply will not compile against v0.14.0 (for good reason, since for all Cargo knows this could silently break the ndarray-csv code in arbitrary ways).

On the library author side, there is the "semver trick" to avoid creating these problems when making a breaking release.

#11

Got it. I understand that cargo would not allow v0.14.0 in the case of ndarray-csv I was just thinking that if bumping the underlying version wasn't possible then maybe I could maintain the 2 types separately in my application such that they could both coexist. Is there some fundamental reason this wouldn't work?

But certainly bumping the version makes the most sense if that is possible, which in this case was possible.

Thanks for taking the time to respond to the earlier posts and review the reference materials.

#12

I don't think so, it just seems to me like something you wouldn't want to maintain for any significant amount of time. But you know the tradeoffs here better than I do so take that with a grain of salt :‌)

#13

Right, not the best solution! I only really thought of it as this one dependency was only needed on the edge of the application for IO, not anywhere else.

Regardless, just fixing the dependency in the dependency (lol) worked and was the best result. The PR has been merged and published as a new ndarray-csv version.

1 Like