Open ejpcmac opened 7 months ago
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.
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.
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 packagingsvdtools
via Nix using naersk, which bases on the Cargo.lock to ensure the reproducibility of the build.