Building with minimum version of dependencies


#1

I recently ran into a problem with my library where a consumer of it was having trouble building it and I couldn’t reproduce it. Turns out I was using bad versions for my dependencies, I had left libc at 0.2.1 and been upgrading it locally but forgot to increase the dependency version as I relied on newer functionality.

It looks like cargo always wants to use the newest version of a library by default. I think that’s a great default, but it does make automated testing more problematic for libraries as they don’t use a Cargo.lock file. And I didn’t see a way with cargo to build with the lowest dependency versions that meet all requirements, which I’d really like to do as part of my CI builds. A workaround to this is to specify exact dependency versions, but I’d prefer not to do that as it locks me out of patch releases since most of my software is pre-1.0.

So my question to everyone here is do they see this as a real problem in practice? If so would a cargo build --min-dep-versions, ideally also being exposed via cargo test, sound like a reasonable approach to address this/


#2

You can manually use cargo update --package foo --precise x.y.z, but I agree it would be nice to have something automatic.

One caveat is that even while your own crate might be perfectly fine with your stated minimum, one of your dependencies might not be, so you won’t be able to force the minimum. e.g. if you need libc-0.2.10, and a dependency needs libc-0.2.20, then you’ll have to use the higher.

Usually cargo resolves that for you, although choosing the highest possible solution. So maybe your --min-dep option could still find that transitive minimum for you, which may still be higher than your own stated minimum.


#3

Interesting, didn’t even think to check the cargo update command for this, but I guess it makes sense. Yes, that’s exactly what I want!

Another option might be to have this be a cargo update option as well, but I think if this was just available for cargo test that would probably cover all use cases.