Well well well, how the turn tables.
Isn’t that the point of dependency lock files? Was committing it not recommended before?!
The problem with locking dependencies of libraries to exactly one version is generally that you get a lot more version conflicts if you use two libraries that have last updated their lock files at different times even if the version range they are compatible with overlaps.
This is not how the resolver works. A comment from the GitHub thread explains it well:
Cargo.lockis not active when you simply use some software, for libraries used as a dependency it’s completely ignored, for applications installed viacargo installit’s ignored by default but can be enabled withcargo install --locked. Only when you are building from within the source tree is it active (e.g. via cloning the repo, or manually downloading and extracting the archive).Yeah, I read the comment threads now too.
On the other hand they also mentioned that that means that the users of the library will not only be the first to run into every problem with newer dependencies but will also be very confused when they check out the library that gives them trouble and the library will compile just fine in its own repository but will break as a dependency.
They also made the good point that there should be more command line options to control lock file usage since some CI environments do mount the source code read-only.
Some advice I found a while back was to commit it for user-facing applications, where it’s more important that they get exactly the same behaviour you tested, but to leave it out for libraries, where the flexibility of dependency versions is more valuable.
It’s weird how much difference a year makes in the Rust world. I had some initial pushback in this PR from 11 months ago, which only expanded the scope of recommendation for tracking
Cargo.locka little.