I understand the community is now more flexible in their recommendation on whether or not to version control Cargo.lock files, leaving it up to the advances in CI to automatically uptick versions, etc. Whereas previously the recommendation was to not version control Cargo.lock files for libraries.
I'm not currently using fancy CI to auto update my libraries so what is the drawback if I'm version controlling Cargo.lock? Since my dependent binaries reference the libraries from git repository paths, does that mean when they clone them they may suffer version conflicts with the library's Cargo.lock file checked in?
If I didn't version control Cargo.lock for my libraries would that help avoid version conflicts by relying instead on the semver syntax of Cargo.toml?
nothing really. the only one potential draw back I can think of is when you merge patches by others, it might cause merge conflicts.
it might result in git merge conflicts if they modify the code, as I mentioned, but it will NOT affect how the transitive dependency versions are calculated (unless some dependencies have non compatible versions per semver).
cargo only use the lock file in the workspace to build. for non-virtual workspaces, this is the same as the top level package, where you run the cargo command. the lock files of the dependencies are ignored.
in other words, the lock file you checked in will only be used when you build the library standalone, not when your library is used as a dependency.
That is the perfect response I was hoping for. I do at times hit collisions and it's forced me to use inequality expressions in my library's Cargo.toml (>=) to mitigate. So I was wondering if the lock file was to blame but I suppose it just is what it is. Semver has a few hard-to-remember rules, especially with 0.x.x versions.