search

cat-in-136 / cargo-generate-rpm

Cargo helper command to generate a binary RPM package
MIT License
92 stars 19 forks source link

Missing Cargo.lock #60

Open orhun opened 1 year ago

orhun commented 1 year ago

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

https://github.com/cat-in-136/cargo-generate-rpm/blob/346e1fe44da57b40e4a7508fa44e988464fb1484/.gitignore#L152-L154

cat-in-136 commented 1 year ago

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 #61 and #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 https://github.com/rust-lang/cargo/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.