Please consider providing a `Cargo.lock`

[vikanezrimaya]

Current Rust best practices recommend committing Cargo.lock even for libraries: https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

Additionally, this makes downstream packaging easier in some places, like nixpkgs, where a Cargo.lock is mandatory for Rust packages. I would love to package the xtr utility for nixpkgs, but the lack of Cargo.lock in your repository complicates things somewhat (while an out-of-tree Cargo.lock can be provided, it would be nice to have it provided in the repository).

Since this package provides an executable binary, it makes sense to provide a Cargo.lock in this repository even under the old guidelines.

[ogoffart]

I'm not a fan of putting the lock file in the repository. This is a tradeoff, and i think it just messes the git history.

Now, if this helps to get xtr packaged, I might reconsider this.

[kaj]

Current Rust best practices recommend committing Cargo.lock even for libraries: https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

That is not what the link says. It has (just) removed the recommendation against comitting Cargo.lock for libraries, and recommends each project to decide for itself.