- Don't use
"*"
dep version requirements. - Add
Cargo.lock
to version control. - Why read to string if you're going to base64-encode and use
Vec<u8>
later anyway?
Rust
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
All good points. I will address them in a later version.
The Cargo.lock thing is weird though, but apparently the builtin .gitignore of codeberg/forgejo has Cargo.lock in it.
In addition to the sibling comment, note that reproducible build systems from Docker to Nix require a lockfile in order to be reproducible, and if you don't provide one, then somebody downstream will provide it instead. By checking in Cargo.lock
, you ensure control over the precise versions of your dependencies for all downstream users.
Regarding Cargo.lock
, the recommendation always was to include it in version control for application/binary crates, but not library ones. But tendencies changed over time to include it even for libraries. If a rust-toolchain
file is tracked by version control, and is pinned to a specific stable release, then Cargo.lock
should definitely be tracked too [1][2].
It's strictly more information tracked, so there is no logical reason not to include it. There was this concern about people not being aware of --locked
not being the default behaviour of cargo install
, giving a false sense of security/reliability/reproducibility. But "false sense" is never a good technical argument in my book.
Anyway, your crate is an application/binary one. And if you were to not change the "*"
dependency version requirement, then it is almost guaranteed that building your crate will break in the future without tracking Cargo.lock
;)
TIL about OSC52, this is very good to know, thank you for sharing!
Thanks for creating and sharing this tool! Will definitely add it to my toolbelt!