`cargo install jwt-ui` fails

[fadeevab]

Describe the bug
Fresh cargo install jwt-ui fails with build errors.

Log

error[E0308]: mismatched types
    --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jwt-ui-1.1.0/src/ui/encoder.rs:133:5
     |
132  |     textarea.set_block(
     |              --------- arguments to this method are incorrect
133  | /     Block::default()
134  | |       .borders(Borders::ALL)
135  | |       .style(get_input_style(&text_input.input_mode, light_theme)),
     | |__________________________________________________________________^ expected `ratatui::widgets::block::Block<'_>`, found `ratatui::widgets::Block<'_>`
     |
     = note: `ratatui::widgets::Block<'_>` and `ratatui::widgets::block::Block<'_>` have similar names, but are actually distinct types
note: `ratatui::widgets::Block<'_>` is defined in crate `ratatui`
    --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.25.0/src/widgets/block.rs:233:1
     |
233  | pub struct Block<'a> {
     | ^^^^^^^^^^^^^^^^^^^^
note: `ratatui::widgets::block::Block<'_>` is defined in crate `ratatui`
    --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.26.2/src/widgets/block.rs:64:1
     |
64   | pub struct Block<'a> {
     | ^^^^^^^^^^^^^^^^^^^^
     = note: perhaps two different versions of crate `ratatui` are being used?
note: method defined here
    --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tui-textarea-0.4.0/src/textarea.rs:1648:12

To Reproduce
Steps to reproduce the behavior or a screencast

1. cargo install jwt-ui

Expected behavior
I expect it installs jwt-ui properly with no errors.

Desktop (please complete the following information):

• WSL2
• Windows Terminal
• bash, rustc 1.77.2, rustup 1.27.0
• jwt-ui version: 1.1.0

[anewton1998]

I have the same issue on NixOS 23.11.5742.219951b495fc (Tapir) with Rust toolchain 1.70.0-x86_64-unknown-linux-gnu

[tolik518]

Same error on Ubuntu 20.04 with cargo 1.77.2 (e52e36006 2024-03-26) and rustc 1.77.2 (25ef9e3d8 2024-04-09)

   Compiling jwt-ui v1.1.0
error[E0308]: mismatched types
    --> /home/developer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jwt-ui-1.1.0/src/ui/encoder.rs:133:5
     |
132  |     textarea.set_block(
     |              --------- arguments to this method are incorrect
133  | /     Block::default()
134  | |       .borders(Borders::ALL)
135  | |       .style(get_input_style(&text_input.input_mode, light_theme)),
     | |__________________________________________________________________^ expected `Block<'_>`, found a different `Block<'_>`
     |
     = note: `Block<'_>` and `Block<'_>` have similar names, but are actually distinct types
note: `Block<'_>` is defined in crate `ratatui`
    --> /home/developer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.25.0/src/widgets/block.rs:233:1
     |
233  | pub struct Block<'a> {
     | ^^^^^^^^^^^^^^^^^^^^
note: `Block<'_>` is defined in crate `ratatui`
    --> /home/developer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.26.2/src/widgets/block.rs:64:1
     |
64   | pub struct Block<'a> {
     | ^^^^^^^^^^^^^^^^^^^^
     = note: perhaps two different versions of crate `ratatui` are being used?
note: method defined here
    --> /home/developer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tui-textarea-0.4.0/src/textarea.rs:1648:12
     |
1648 |     pub fn set_block(&mut self, block: Block<'a>) {
     |            ^^^^^^^^^

error[E0277]: the trait bound `impl ratatui::widgets::Widget + '_: Widget` is not satisfied
   --> /home/developer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jwt-ui-1.1.0/src/ui/encoder.rs:138:19
    |
138 |   f.render_widget(textarea.widget(), chunks[0]);
    |     ------------- ^^^^^^^^^^^^^^^^^ the trait `Widget` is not implemented for `impl ratatui::widgets::Widget + '_`
    |     |
    |     required by a bound introduced by this call
    |
    = help: the following other types implement trait `Widget`:
              BarChart<'a>
              ratatui::widgets::Block<'a>
              Canvas<'a, F>
              Chart<'a>
              ratatui::widgets::Clear
              Gauge<'a>
              LineGauge<'a>
              List<'a>
            and 4 others
note: required by a bound in `Frame::<'_>::render_widget`
   --> /home/developer/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.25.0/src/terminal.rs:614:12
    |
612 |     pub fn render_widget<W>(&mut self, widget: W, area: Rect)
    |            ------------- required by a bound in this associated function
613 |     where
614 |         W: Widget,
    |            ^^^^^^ required by this bound in `Frame::<'_>::render_widget`

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `jwt-ui` (bin "jwtui") due to 2 previous errors
error: failed to compile `jwt-ui v1.1.0`, intermediate artifacts can be found at `/tmp/cargo-installaKm7zH`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Edit: git clone the latest version and running it with cargo run works though, looks like the latest version just needs to be pushed to crate.io

Edit 2: I could pinpoint where the error is coming from and created a PR #36

[joshka]

The general answer for installation problems with cargo install is to use the versions of the dependencies that are defined by the app in the lockfile. The following installs fine:

cargo install jwt-ui --locked

I'd suggest adding --locked to the installation docs of any app.

[tolik518]

@joshka its probably some basics I'm missing, but could you please elaborate how the version mismatch happens if you don't use --locked?

[joshka]

Grab cargo tree and run it with the inverse param (-i) passing the package to show (ratatui). You'll get an error that tells you there's two versions and will have to specify each dep via as e.g. ratatui@26.2.0 or whatever for each.

From there take a look at the dependency resolution rules and make sure you understand how they work. 0.x.y and 0.x+1.z are (effectively) major version bumps and explicitly not compatible. Cargo version spec syntax is weird and takes a bit to understand, but it's worth the journey to really understand the resolution logic.

[fadeevab]

@joshka Thanks for this summary. A quick feedback:

1. Indeed, cargo install jwt-ui --locked solves the issue. Need to add it to the README.
2. I think there is confusion that cargo install ignores the Cargo.lock by default (unless the --locked flag is used) and that differs from the behavior of cargo build and how other package managers (usually) work. I found it's not the new topic, there is a 5 years old open discussion. Developers chose in favor of ignoring the lock file because it supposedly makes security updates get delivered faster.

[joshka]

Taking a bit of a deeper look, because I've seen this a few times with tui-textarea. The actual problem here is pretty complex (it's called out multiple times as a problem in the cargo book: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-version-requirements https://doc.rust-lang.org/cargo/reference/resolver.html#unexpected-dependency-duplication)

tui-textarea specifies ratatui { version = ">=0.23.0, <1", ... }
jwt-ui specifies ratatui {version = "0.25.0" }

Dependency resolution attempts to use the latest version that satisfies each constraint (tui-textarea = 0.26.2, jwt-ui 0.25.0). If jwt-ui never used any parts of tui-textarea that expose types from the different version of ratatui, this would be fine (but that's not what happens). In effect, the dependency resolution makes your app have two incompatible types, and because of the way tui-textarea specifies their deps, this will occur for every library that uses tui-textarea whenever we bump the 0.x in Ratatui.

The implied rationale from tui-textarea's perspective is that it is compatible with versions of Ratatui from 0.23.0 through the current version and the developer doesn't want the hassle of updating this, but the desired effect and the intended one are probably out of whack.

I'll raise a PR for this on the tui-textarea, as that shouldn't happen. From a current app user of tui-textarea 0.4, you should treat that dependency as the same as a dependency on 0.26.y, or whatever the latest Ratatui 0.x version is until that's fixed.

[deepu105]

Thanks everyone for chiming in. Indeed I have --locked in the instructions for my other project (KDash) but missed it here.