1

Let's say we want to add jsonwebtoken 8.2.0 to our Cargo.toml. That crate is dependent on ring 0.16.20, which is dependent on the web-sys 0.3.60 crate and that dependency is declared like this:

[target.'cfg(all(target_arch = "wasm32", target_vendor = "unknown", target_os = "unknown", target_env = ""))'.dependencies]
web-sys = { version = "0.3.37", default-features = false, features = ["Crypto", "Window"] }

For my project I don't need any JS/Wasm-related stuff whatsoever. But I noticed in my Cargo.lock several such dependencies were added as a result of that web-sys crate (such as wasm-bindgen for example). Is there a way to avoid that "noise"?

at54321
  • 8,726
  • 26
  • 46
  • Why do you care about the contents of your `Cargo.lock` if those dependencies are not being downloaded and compiled? – Locke Dec 07 '22 at 22:05
  • Just seem a bit redundant to me. Perhaps not a big deal, but still... if there is a way to avoid it (or not), I'd like to know. – at54321 Dec 07 '22 at 22:11

1 Answers1

2

The Cargo.lock decides versions to be used for compilation on all possible platforms and to my knowledge, there is no way to override that.

Consider: Not doing so would be a headache. If someone on a new platform cloned your repo and built your crate, they'd have to have their Cargo.lock modified (and send you a patch?). If you updated a crate dependency on your system it would only update the locked versions for your platform, other people might end up with an inconsistent lock. To avoid the headache, just let cargo do with the Cargo.lock as it wants and ignore the contents.

If you want to reduce the noise a bit and hide the lock file diffs from git output, you could mark Cargo.lock as a binary file like shown here:

echo >>.gitattributes Cargo.lock binary

(though I don't know whether that won't have weird effects on windows line endings.)

Caesar
  • 6,733
  • 4
  • 38
  • 44
  • That was my impression as well. I agree in certain scenarios it could be a headache, although that potential risk could have been something that is left for users to decide. – at54321 Dec 08 '22 at 07:22
  • 1
    About the "mark as a binary" hack - TBH, that wouldn't really make me sleep better at night. :) I think that brings more harm than good. But thanks for pointing it out anyway. – at54321 Dec 08 '22 at 07:25
  • I tried adding `target = ["x86_64-unknown-linux-gnu"]` to `.cargo/config.toml` and that didnt remove deps not needed for that target. Seems it is only a hint. IMO it would be worth adding a 'stronger' `only_targets = ...` to indicate all other targets should be ignored. – John Vandenberg Apr 18 '23 at 21:56
  • @JohnVandenberg Again, what for? `Cargo.lock` is a bunch of noise either way, you neither should nor can care about what's in it. Sometimes I wish it was in some binary format to underline that point. (There may be other points to such a setting, e.g., nicer error messages when compiling for an unsupported target, similar to what comes from `package.rust-version` in `Cargo.toml`. But that's orthogonal.) – Caesar Apr 18 '23 at 22:41
  • The contents are critical to identify ways to remove unnecessary or necessary but undesirable dependencies that creep in. Necessary in a world where SBOM need to be maintained, and provided to auditors or even clients. – John Vandenberg Apr 19 '23 at 03:18
  • Then you're using `Cargo.lock` for something it's not made for. For identifying unnecessary dependencies, use `cargo-udeps` (or `cargo-machete` or a simple bash script that checks whether removing something from `[dependencies]` breaks the build). For SBOM, use `cargo-tree` or whatever `cargo crev verify --target` does. (If you're willing to hack around, you could also `[patch.crates-io]` unused dependencies to some empty crate.) – Caesar Apr 19 '23 at 03:32