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...
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.
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.