commit the Cargo.lock

[ejpcmac]

The official guideline for Rust project was originally not to commit the Cargo.lock for libraries. However, this has been recently revised to ensure all developers in a project work in a consistent and reproducible environment.

Furthermore, svdtools is a CLI, for which committing the Cargo.lock was also encouraged. It will also help packaging svdtools via Nix using naersk, which bases on the Cargo.lock to ensure the reproducibility of the build.

[therealprof]

The problem I have with having a Cargo.lock is that it automatically turns a crate into high maintainance mode with lots of churn to keep the dependencies bumped and frequent maintenance releases. I don't think it is sustainable for us to do this for the rather little gain; reproducible builds are great for projects with high security impact but I don't think that svdtools qualifies.

I will not stand in the way if people are willing to spend the time to do those unnecessary chores and entertain the email spam something like dependabot will create, but for me this is a high-pain/no-gain idea.

[ejpcmac]

While I understand your concerns, this would be aligned with what is currently done fore svd2rust since this commit.

By the way, on a project we are still using svd2rust 0.28.0—we’ll update soon™ due to the soundness fix. In svd2rust 0.28.0, the Cargo.lock was still not committed, so when packaging it in the flake.nix for our project, we needed to generate one to meet the reproducibility constrain required by Nix. As it was different from the one previously packages in nixpkgs, the behaviour of svd2rust has changed while not changing its version. The generated warnings and documentation are different when the descriptions are empty in the SVD, probably due to an update in the svd crate. While this is a minor change, I still find it incorrect that a program can change its behaviour without changing its version.