2

For example, I use barcoders crate:

barcoders = {version = "0.10.0", features = ["image",]}

Is it possible to specify which version of image this dependency should use?

Something like 

barcoders = {version = "0.10.0", features = ["image=0.22.3",]}

Because it uses image crate version 0.18.0 and in my project I use latest 0.22.3.

Does it mean that there's only 2 ways to resolve that:

  1. I downgrade version in my package
  2. Barcoders dependency get updated
Nikolai Golub
  • 3,327
  • 4
  • 31
  • 61
  • 1
    Feature names are separate from dependency names, so no, you can't specify a version for them. They are also always _additive_, i.e. if there are multiple crates depending on the same version of crate `foo`, and one of them enables feature `bar`, you will end up with a single version of `foo` with feature `bar` enabled. – Sven Marnach Nov 27 '19 at 21:59
  • 1
    In general, it's not a problem to have more than one version of the `image` crate in your project. It _may_ be a problem if `barcoders` uses types from the `image` crate in its external interface. – Sven Marnach Nov 27 '19 at 22:01

2 Answers2

2

No, there is no way to specify the version for a dependency's (optional) dependency. This makes sense, as your dependency run their tests only against the version they specify in their Cargo.toml. In this case, as it appears everything you're doing uses open source, you could fork barcoders, update the dependency, run the test suite and if it passes, use your fork. It would also be polite to open an issue in that case.

If barcoders wasn't open-source, so you couldn't fork it, your best bet would be to switch to the version of image that barcoders uses. If your crate is a library, it may be annoying to expose a public interface that uses outdated libraries, but that's life. The "proper" solution to this problem is to wait until image has a 1.0 release, which is basically a forward compatibility promise, then barcoders can specify image = "^1" (i.e. >=1.0.0 <2.0.0). I mention this "solution" only because you appear to have commit privileges on barcoders, in fact you solved your own problem by updating the image dependency in barcoders.

As one of the comments points out, this version compatibility issue is less fragile that it at first seems. So long as types from different versions of some dependency crate don't cross api boundaries, your project can include any number of versions of that dependency simultaneously. Working with multiple versions of libraries took some work from the rust team on name mangling, which you can read about here

asky
  • 1,520
  • 12
  • 20
0

No, you can't, and shouldn't, and shouldn't worry.

Libraries were developed at a single point in time, used dependencies with a certain API. The dependency is likely to change some of that between major versions (changing the type a function returns, exposing different patterns, or whatever). This may make it unable to compile anymore. To really update something, you might need to change parts of the code that is using the dependency in the first place.

This is open source world, so you can do so and publish a pull request in the original crate to update. It might be appreciated, but don't underestimate the care that needs to be taken to not break other people's crates yourself when doing so. Or make your own fork of the crate that updates it just for you.

But you are probably just worried seeing duplicates of the same crate with different versions during compilation. Cargo indeed compiles with different versions, so all calls to the dependended crate will receive what the developer expected when he/she wrote it. This is not a problem, in performance, or amount of instructions that end up in the binary. Just stop worrying.

LotB
  • 461
  • 4
  • 10