Include Cargo.lock for reproducible builds #107
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Originally there were guidelines to not check in a Cargo.lock for libraries. Though this has long changed, so it makes sense to add it. I currently go through all the issues and open PRs and once I'm done I'll add the Cargo.lock as you suggested. |
This project provides a library and an executable. Including a Cargo.lock allows the executable to be built reliably (and is expected by third-parties, like Nixpkgs). Those depending on the library are unaffected, since the Cargo.lock files from dependencies will be ignored.
vmx
approved these changes
Sep 29, 2025
|
I've just rebased that commit and updated the Cargo.lock file. Thanks @Warbo and sorry for taking so long. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This project provides a library and an executable. Including a Cargo.lock allows the executable to be built reliably (and is expected by third-party tools, like Nixpkgs). I think those depending on the library are unaffected, since the Cargo.lock files from dependencies will be ignored?
I'm not really a Rust programmer, so don't know the ins-and-outs of committing these files (it was previously in
.gitignore); but I needed it to make a Nix package, so maybe it's useful for others?