This commit updates the FAQ to recommend to always commit Cargo.lock in all projects, both binaries and libraries. The FAQ previously discouraged Cargo.lock in libraries.
The question of changing t...
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.lock is not active when you simply use some software, for libraries used as a dependency it’s completely ignored, for applications installed via cargo install it’s ignored by default but can be enabled with cargo 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).
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.
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:
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.