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