Problems compiling on macOS: “perhaps two different versions of crate tui are being used”

[atroche]

Here's the output of cargo install --force xplr: https://gist.github.com/atroche/82de1ee6aafa1c4f6cc125829caa7306

error[E0308]: mismatched types
   --> /Users/alistair/.cargo/registry/src/github.com-1ecc6299db9ec823/xplr-0.13.1/src/ui.rs:569:69
    |
569 | ...                   .unwrap_or_else(|e| Text::raw(format!("{:?}", e))),
    |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `tui::text::Text`, found a different struct `tui::text::Text`
    |
    = note: perhaps two different versions of crate `tui` are being used?

error[E0308]: `match` arms have incompatible types
   --> /Users/alistair/.cargo/registry/src/github.com-1ecc6299db9ec823/xplr-0.13.1/src/ui.rs:570:55
    |
567 |   ...                   match out {
    |                         --------- `match` arms have incompatible types
568 |   ...                       Ok(o) => ansi_to_text(o.bytes())
    |  ____________________________________-
569 | | ...                           .unwrap_or_else(|e| Text::raw(format!("{:?}", e))),
    | |________________________________________________________________________________- this is found to be of type `tui::text::Text<'_>`
570 |   ...                       Err(e) => Text::raw(e.to_string()),
    |                                       ^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `tui::text::Text`, found a different struct `tui::text::Text`
    |
    = note: perhaps two different versions of crate `tui` are being used?

macOS 10.15.17
rustc 1.52.1
cargo 1.52.0

[sayanarijit]

Probably related to ratatui/ansi-to-tui@884b173

Not sure why though, I pin every dependency and so it shouldn't have affected xplr.

[sayanarijit]

Weird it installs ansi-to-tui v0.2.2 while I have pinned it to 0.2.0.

[sayanarijit]

I see, as per https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-cratesio 0.2.0 is equivalent to ^0.2.0.

[sayanarijit]

@atroche The issue seems to be fixed. Can you try again?

[atroche]

that fixed it :)

thanks!

[maximbaz]

For future reference, make sure to always use --locked flag with cargo build or cargo install, it will actually use the dependency versions that project maintainer has tested with and pinned in Cargo.lock, without the flag cargo will try to play smart and download newer version of dependencies, which as we now know could be suddenly broken 🙂

[sayanarijit]

Thanks... It was a surprise coming from poetry. I thought it was Cargo.lock's job to lock the dependencies.

[maximbaz]

Surprisingly in quite a few languages .lock files are not being used by default unless explicitly asked with some extra flag like --locked, I completely agree with you 🙂

[sayanarijit]

Wait there's no change.

➜  xplr git:(main) cargo build --release --locked
    Finished release [optimized] target(s) in 0.03s
➜  xplr git:(main) gst
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
➜  xplr git:(main)

[sayanarijit]

Oh that's user-side command. I'll document it.

[maximbaz]

Yeah exactly, you already have some dependencies cached, so probably cargo is not downloading anything, but if I install or build xplr on a clean machine and cargo needs to download something, having --locked or not will result into potentially downloading different versions of dependencies

[maximbaz]

I'd also recommend using this flag in CI, for consistency :)