WIP: bump ratatui to 0.30.0

[fujiapple852]

See https://github.com/ratatui/ratatui/releases/tag/ratatui-v0.30.0-alpha.3

[fujiapple852]

Blocked on MSRV:

Crate source was found to be incompatible with Rust version '1.78.0`

Ratatui 0.30.0 is de-facto 1.85 (2024 edition): Cargo.toml though there seems to be a discrepancy with the BREAKING-CHANGES.md file.

Trippy 0.14.0 is intended to have an MSRV of 1.81.

[fujiapple852]

@orhun is this the right way to handle the change in Terminal in 0.30.0?

[orhun]

Looks correct to me... I don't remember the change led to this though. Can you share some references that requires this change?

[fujiapple852]

When I bumped the Ratatui version and tested it failed with:

error[E0277]: `?` couldn't convert the error to `std::io::Error`
  --> crates/trippy-tui/src/frontend.rs:80:55
   |
73 | fn run_app<B: Backend>(terminal: &mut Terminal<B>, app: &mut TuiApp) -> io::Result<ExitAction> {
   |                                                                         ---------------------- expected `std::io::Error` because of this
...
80 |         terminal.draw(|f| render::app::render(f, app))?;
   |                  -------------------------------------^ the trait `std::convert::From<<B as ratatui::backend::Backend>::Error>` is not implemented for `std::io::Error`
   |                  |
   |                  this can't be annotated with `?` because it has type `Result<_, <B as ratatui::backend::Backend>::Error>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: consider introducing a `where` clause, but there might be an alternative better way to express this requirement
   |
73 | fn run_app<B: Backend>(terminal: &mut Terminal<B>, app: &mut TuiApp) -> io::Result<ExitAction> where std::io::Error: std::convert::From<<B as ratatui::backend::Backend>::Error> {
   |                                                                                                +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I did some digging at the time and I think it relates to this: ratatui/ratatui#1775 (which is correctly marked as a breaking change)

[fujiapple852]

This also works and is likely better:

fn run_app<B: Backend<Error = io::Error>>(
    terminal: &mut Terminal<B>,
    app: &mut TuiApp,
) -> Result<ExitAction, B::Error> {

[j-g00da]

In 0.30 io::Error is no longer explicitly used for Backend errors, built-in backends (except TestBackend) still use io::Error, so this should in most cases be backward compatible, but when using the Backend trait directly, the associated error type is unknown, so it requires additional bound (as you did).

[joshka]

You can probably use DefaultTerminal

[j-g00da]

You can probably use DefaultTerminal

Oh I didn't see your comment, yeah: #1588 (comment)

[j-g00da]

I think this can be simply

Suggested change

	) -> Result<ExitAction, B::Error> {
	) -> io::Result<ExitAction> {

since your bound already requires B::Error to be io::Error.

[j-g00da]

Also, since you are only using crossterm, you can also just get rid of the generic type parameter completely:

fn run_app(
     terminal: &mut DefaultTerminal,
     app: &mut TuiApp,
 ) -> io::Result<ExitAction> {

DefaultTerminal is an alias for Terminal<CrosstermBackend> and CrosstermBackend uses io::Error.

[j-g00da]

Blocked on MSRV:

Crate source was found to be incompatible with Rust version '1.78.0`

Ratatui 0.30.0 is de-facto 1.85 (2024 edition): Cargo.toml though there seems to be a discrepancy with the BREAKING-CHANGES.md file.

Trippy 0.14.0 is intended to have an MSRV of 1.81.

This is an error, the MSRV is 1.85.0
ratatui/ratatui#1896

[fujiapple852]

@j-g00da @joshka DefaultTerminal works and is much cleaner, thank you.

[joshka]

This definitely needs rust 1.85 now due to the 2024 edition changes.

[fujiapple852]

@joshka yes, i'm considering reducing Trippy's Rust version policy from 12 months down to 6 months, which would put the next release on 1.85, roughly.

It is a balance between trying to use an old enough toolchain to be supported on various distros and new enough to keep up with the Rust library ecosystem. I've found that in practice 12 months is to long, the Rust world moves on to quickly (especially around the edition bump) and so I think 6 months may be a better balance.

[joshka]

Our philosophy in Ratatui is that we generally won't update the required version beyond N-2. This gives people at least 3 months to work out what they're doing and doesn't artificially prevent us from taking advantage of new things for too long (e.g. we waited until 1.87 was out to flip over to the 2024 edition). Obviously your use cases aren't ours.

It is a balance between trying to use an old enough toolchain to be supported on various distros and new enough to keep up with the Rust library ecosystem. I've found that in practice 12 months is to long, the Rust world moves on to quickly (especially around the edition bump) and so I think 6 months may be a better balance.

Good news - Debian Trixie looks like it will support 1.85. but by the time it comes out I'd guess Ratatui will likely have moved past that version...

That said, I'm very apprehensive about distros pinning to versions like this. Artificial limitations on calling functions that have been available for years (rust 1.63 was released in 2022), are a game that I choose not to participate in unless forced to.

Case in point, I had a job interview the other day where one part of the solution was a simple method introduced in the std lib in 1.80, but coderpad runs 1.72, so I had to polyfill the impl live. That was somewhat annoying.