Checking in Cargo.lock

[Hofer-Julian]

Like many Rust libraries, we don't check Cargo.lock into git. I think we should re-evalutate that decision.

Lock files have many advantages. For downstream Cargo.lock is disregarded, so only advantages for rattler developers matter:

• Multiple checkouts of the same commit have the same dependency tree (you and CI, you and your colleague)
• You can go back to older commits and have the same dependency tree as when the commit was made

The main argument against checking in the lock file is, that as mentioned before, the dependencies of downstream users will be locked differently. A new version of your dependencies might break your users' setup when they update, but you don't notice since the dependencies are locked.

With Dependabot that problem is easily avoided. You just let it update your Cargo.lock on a regular basis and merge the PR if CI is green and deal with the problem if CI is red. It's even nicer since you see which crates updated and are therefore responsible for the breakage.

That is one of the reasons why the Cargo team moved away from their recommendation to "commit Cargo.lock file for packages with binaries but not libraries": https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

The new msrv aware resolver should avoid even further breakage for downstream users that we have to keep in mind.

[pavelzw]

another argument:
with rattler-index we actually sort-of ship binaries (we don't build them here but to conda-forge). at least for the rattler-index build i would prefer a lockfile rather than yolo-building in conda-forge CI

[baszalmstra]

It makes sense to me, both py-rattler and js-rattler also have checked in lock-files.

[pavelzw]

#1117