Open jonasmalacofilho opened 4 years ago
Published one in 0.4.8.
Thank you!
@jonasmalacofilho, question: is it important for you that Cargo.lock is present in the git repository and the GitHub-generated source tars under https://github.com/dtolnay/cargo-llvm-lines/releases? I would prefer if you'd be able to package from the published crates.io tars instead. Cargo automatically includes a Cargo.lock in those as part of cargo publish
, regardless whether there is one in the git repo. Is packaging the crates.io published releases materially more difficult to arrange on your end?
https://crates.io/api/v1/crates/cargo-llvm-lines/0.4.33/download
$ tar tf cargo-llvm-lines-0.4.33.crate
cargo-llvm-lines-0.4.33/.cargo_vcs_info.json
cargo-llvm-lines-0.4.33/.github/FUNDING.yml
cargo-llvm-lines-0.4.33/.github/workflows/ci.yml
cargo-llvm-lines-0.4.33/.gitignore
cargo-llvm-lines-0.4.33/Cargo.lock
cargo-llvm-lines-0.4.33/Cargo.toml
cargo-llvm-lines-0.4.33/Cargo.toml.orig
cargo-llvm-lines-0.4.33/LICENSE-APACHE
cargo-llvm-lines-0.4.33/LICENSE-MIT
cargo-llvm-lines-0.4.33/README.md
cargo-llvm-lines-0.4.33/src/count.rs
cargo-llvm-lines-0.4.33/src/main.rs
cargo-llvm-lines-0.4.33/src/opts.rs
cargo-llvm-lines-0.4.33/src/table.rs
I generally look over the changes in each release, and I find it easier to do that commit-by-commit.
Therefore, building from the published crate would add the extra step of, at the end, making sure that the crate contents match the corresponding tag in the repository. But that shouldn't be hard.
Hi,
Could a
Cargo.lock
file be included in future releases so that downstream Linux packages can be reproducible[1] and, potentially, more reliable?P.S. Just packaged this for ArchLinux: cargo-llvm-linesAUR.