Skip to content

docs: install with --locked #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 14, 2025
Merged

Conversation

lautarodragan
Copy link
Contributor

@lautarodragan lautarodragan commented May 14, 2025

Hi! Thanks for creating and sharing this wonderful cli app. I was looking for a lightweight tool to read spreadsheets (LibreOffice is massive and overkill for my use-case), and this is perfect.

I don't know if this suggestion is correct, but, in my case, cargo run / cargo build runs fine, but cargo install breaks with ~10 errors. Apparently, it's because cargo install doesn't completely honor Cargo.lock unless --locked (or --frozen) is passed.

All the reported errors, when running without --locked, are related to the trait bound impl ratatui::widgets::Widget + '_: Widget is not satisfied and mismatched types.

It looks like it resolves two different versions of ratatui, 0.24 and 0.29:

= note: `Style` and `ratatui::style::Style` have similar names, but are actually distinct types
note: `Style` is defined in crate `ratatui`
    --> /home/taro/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.24.0/src/style.rs:192:1
     |
192  | pub struct Style {
     | ^^^^^^^^^^^^^^^^
note: `ratatui::style::Style` is defined in crate `ratatui`
    --> /home/taro/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ratatui-0.29.0/src/style.rs:247:1
     |
247  | pub struct Style {
     | ^^^^^^^^^^^^^^^^
     = note: perhaps two different versions of crate `ratatui` are being used?

I think the "culprit" seems to be tui-textarea:

ratatui = { version = ">=0.23.0, <1", default-features = false, optional = true }

This difference in default behavior between run and install seems to be a thing, and it's definitely very counter-intuitive.

I can kinda reproduce it if I remove the Cargo.lock:

$ cargo tree | grep tui
├── ratatui v0.24.0
└── tui-textarea v0.4.0
    ├── ratatui v0.24.0 (*)

$ rm Cargo.lock

$ cargo clean

$ cargo tree | grep tui
├── ratatui v0.24.0
└── tui-textarea v0.4.0
    ├── ratatui v0.29.0

rm'ing Cargo.lock actually causes cargo build to fail.

Upgrading ratatui to "0.27.0" and tui-textarea to "0.5.0" "fixes" this issue.

$ cargo tree | grep tui
├── ratatui v0.27.0
└── tui-textarea v0.5.3
    ├── ratatui v0.27.0 (*)

I opened #11 with that dependency upgrade.

Optional dependencies are always such a pain...

@fuhan666 fuhan666 merged commit 0f53940 into fuhan666:main May 14, 2025
@lautarodragan lautarodragan deleted the patch-1 branch May 14, 2025 23:13
@lautarodragan
Copy link
Contributor Author

Thanks @fuhan666 :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants