Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Cargo.lock file #28

Closed
samford opened this issue Oct 27, 2019 · 2 comments
Closed

Add Cargo.lock file #28

samford opened this issue Oct 27, 2019 · 2 comments

Comments

@samford
Copy link

samford commented Oct 27, 2019

In the process of making changes to formulae in the Homebrew package manager, I noticed that shellharden was one of a handful of Rust binary projects without a Cargo.lock file in version control. The Cargo book recommends the following (source):

If you’re building an end product, which are executable like command-line tool or an application, or a system library with crate-type of staticlib or cdylib, check Cargo.lock into git.

More information about the reasoning can be found in the "Why do binaries have Cargo.lock in version control, but not libraries?" section of the Cargo FAQ.

The Cargo.lock file helps package managers to keep builds reproducible, since cargo install simply uses the latest dependency versions unless the --locked flag is added to the command, in which case it will use the versions outlined in Cargo.lock. Without a Cargo.lock file, there's a chance that a dependency update will break the build sometime in the future, which is something I've already encountered with other Rust binary projects.

I know shellharden currently doesn't have any dependencies but could you please consider checking Cargo.lock into version control? There's a chance that Homebrew might roll out the --locked flag as a default for building Rust projects from source, so it would be helpful to have the Cargo.lock file available here to avoid errors.

anordal added a commit that referenced this issue Oct 27, 2019
@anordal
Copy link
Owner

anordal commented Oct 27, 2019

Ok, I don't want to be the bully that requires disabling the --locked flag.

I added it in master, so it will be part of the next release. I haven't begun any of the feature work I had planned for the next version, so there is little point in a new release yet (from a user's point of view). But until then, may I suggest cherry-picking 22db5fc?

Thanks for letting me know!

@samford
Copy link
Author

samford commented Oct 27, 2019

I agree that there's no need to push out a release just for this. Thanks for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants