search

freedomofpress / securedrop-signal-poc

prototype e2e server and source + journalist clients for securedrop
GNU General Public License v3.0
5 stars 3 forks source link

Don't ignore Cargo.lock #30

Closed conorsch closed 2 years ago

conorsch commented 2 years ago

The rust book recommends not version-controlling the cargo lockfile, with specific versions of dependencies and their checksums, when creating a library [0]. However, it goes on to clarify that a cdylib (which is the crate type we're dealing with here) should have its dependencies locked:

If you’re building an end product, which are executable like command-line tool or an application, or a system library with crate-type of staticlib or cdylib, check Cargo.lock into git.

We definitely want to make sure we know exactly which dependencies are being pulled in, so that over time the build environment in multiple dev envs is identical. This is especially important because this repo isn't seeing high-churn right now, so non-version-controlled Cargo.lock files will vary greatly between environments over time.

[0] https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html#cargotoml-vs-cargolock

conorsch commented 2 years ago

@cfm I've added a Cargo.lock that results in a working build, based on your changes in #29. Given that we're overdue for some dependency updates, I'd like to track the specific versions before engaging in that work (cf #2).