Build fails if Cargo.lock is not used

[julianneswinoga]

When installing via a local clone, I get a warning/compile error.

$ cargo install --path . -j8 --force
  Installing tealdeer v1.4.1 (~/tools/tealdeer)
    Updating crates.io index
   Compiling tealdeer v1.4.1 (~/tools/tealdeer)
warning: use of deprecated associated function `clap::Arg::<'help>::hidden`: Replaced with `Arg::hide`
   --> src/main.rs:125:9
    |
125 |         hidden = true
    |         ^^^^^^
    |
    = note: `#[warn(deprecated)]` on by default

error[E0599]: no variant or associated item named `HelpRequired` found for enum `AppSettings` in the current scope
  --> src/main.rs:59:31
   |
59 | #[clap(setting = AppSettings::HelpRequired)]
   |                               ^^^^^^^^^^^^ variant or associated item not found in `AppSettings`

For more information about this error, try `rustc --explain E0599`.
warning: `tealdeer` (bin "tldr") generated 1 warning
error: failed to compile `tealdeer v1.4.1 (~/tools/tealdeer)`, intermediate artifacts can be found at `~/tools/tealdeer/target`

Caused by:
  could not compile `tealdeer` due to previous error; 1 warning emitted

tealdeer hash is 1a3624d0116, cargo version:

$ cargo --version
cargo 1.57.0 (b2e52d7ca 2021-10-21)

[dbrgn]

Huh, that's weird. cargo build and also cargo build --release work fine. Does someone know what's going on?

[niklasmohrin]

This is weird: Building (and even cargo run) works fine, but using the command you specified (cargo install --path . -j8 --force) gives me the same error. I can even cargo build and cargo build --release in a fresh clone. While the immediate fix from our side seems straight-forward (just do what the compiler is telling us to), this is still weird. We should probably further investigate or open an issue at clap if we don't find the issue on our part.

[dbrgn]

Ahh, I found the reason: cargo install ignores the lockfile, and thus implicitly upgrades all dependencies. Well, that's a stupid idea, the lockfile is there for a reason.

[niklasmohrin]

@cameronswinoga That means you also get an immediate fix: cargo install --path . --force --locked :)

Let's still keep this open and fix it though

[dbrgn]

@cameronswinoga That means you also get an immediate fix: cargo install --path . --force --locked :)

Ah, nice, I wasn't aware of that option!

[dbrgn]

Let's still keep this open and fix it though

I'll handle that, since there's a new clap option I wanted to add!

[julianneswinoga]

@dbrgn very strange behaviour! Is that documented as a "feature" somewhere or is it a bug in cargo?

[dbrgn]

I assume it's a feature. If you install from crates.io (which is the default), I believe there is no lockfile being shipped with the crate. If you install from source, you'll apparently have to use --locked if you want to use the lockfile.