Missing Cargo.lock

[orhun]

Cargo.lock should be committed to the repository since this is a binary application.

cargo-generate-rpm/.gitignore

Lines 152 to 154 in 346e1fe

	# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
	# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
	Cargo.lock

[cat-in-136]

Your PRs seem correct at first glance, but it is problematic in two respects. For this reason, I have reverted these.

1. If Cargo.lock is to be removed from gitignore, it should also be checked with cargo install --lock, which failed in the github workflow. These two change PR Add Cargo.lock #61 and Build with --locked flag during CI #64 should be handled in unified single PR, not separated.
2. Normally it is expected to run cargo install cargo-generate-rpm, but Cargo.lock is not referenced by cargo install. When installing with reference to Cargo.lock, run cargo install --locked cargo- generate-rpm and you will need to run This is described at Publish lockfile for binary crates rust-lang/cargo#5654. Therefore, the behavior of both cargo install (without --locked) and cargo install --locked should be checked in test.

These points will need to be taken into account and redone.

[orhun]

Alright, that makes sense. Can we clarify what is needed to be done to commit Cargo.lock to the repository? Do you need a single PR for both #61 and #64? Do we need any additional changes in CI to test the behavior of cargo install?

[cat-in-136]

This is only my thought that applies to my own project, if there are test and/or documentation changes in adding a feature, I would like them to be in one pull request (the commits can remain separated).

cargo install cargo-generate-rpm installs the binary file built with the cargo build (without --lock) equivalent. cargo install cargo-generate-rpm --lock installs ones with cargo build --lock. Many people will (without thinking about difference) run it with the former. I do so, too. As of now, I couldn't decide if it is reasonable to test with cargo build --lock only or not, taking that into account.

It is not always the case that the binary executable file package always includes the Cargo.lock file. For example, rust-lang/cargo does not add it. Since "cargo" is an official Rust tool, this does not mean "forgot to add Cargo.lock".

These may be common knowledge to those of you who develop Rust projects on a daily basis. However, your PR description is "too simplistic" for me, and I have many questions after doing my own research. Until these are resolved, I will not be merging this for a while.

[newpavlov]

Personally, I usually commit Cargo.lock even for library crates. It somewhat helps with failures which originate from dependencies. Without it, CI may fail completely unrelated to a PR changes. And with binaries having Cargo.lock helps with reproducibility. It's a bit less concern for Cargo, since it's mainly distributed as pre-compiled binaries using rustup as part of Rust toolchain.