Skip to content

Crate metadata

Facts about the package itself rather than its API. Everything here is read from Cargo.toml, rust-toolchain.toml, deny.toml and the justfile at version 0.6.4.

Package identity and how to depend on it

Field Value
Crate name rtb-tui
Library name in Rust code rtb_tui
Version documented here 0.6.4
Edition 2021
Minimum supported Rust version 1.85
License MIT
Repository https://gitlab.com/phpboyscout/rust/tui
Generated API docs https://docs.rs/rtb-tui 
[dependencies]
rtb-tui = "0.6"

The crate is pre-1.0, so a minor bump may change the public API. Pin to a minor version rather than a major one if you want a quiet upgrade path.

Cargo features

There are none. Cargo.toml declares no [features] table, so:

  • default-features = false changes nothing;
  • there is no way to compile out the wizard, the render helpers or the spinner independently;
  • there is no way to drop miette, serde_json or tabled from the graph while still using the parts that do not need them.

Taking the crate takes all three components and all eight dependencies. If that matters for your binary size, depend on inquire, tabled or console directly instead.

Dependencies

Eight runtime dependencies, all pinned to a caret requirement:

Crate Requirement Features Used for
inquire 0.9.4 default The prompts a WizardStep issues; InquireError is re-exported
tabled 0.22.0 derive render_table, via Style::psql(); re-exported as rtb_tui::tabled
console 0.16.4 default Term::stderr() and the TTY check in Spinner
miette 7.6.0 fancy Diagnostic derive and diagnostic codes on both error enums
thiserror 2.0.19 default Error derive on both error enums
async-trait 0.1.91 default WizardStep::prompt is an async fn in a trait
serde 1.0.229 derive The Serialize bound on render_json
serde_json 1.0.150 default to_string_pretty inside render_json

tokio appears only as a dev-dependency, for the async tests. The crate does not start or require any particular runtime: Wizard::run is a plain async fn and you drive it with whatever executor your binary already has.

miette's fancy feature is the heaviest item in that list: it pulls in the graphical report renderer and its terminal-handling stack. It is on unconditionally.

Banned dependencies

deny.toml refuses these outright, so a change that reintroduces one fails the audit job rather than being caught in review:

Banned crate Reason
rust-tool-base The crate is extracted from the framework and must never depend back on it
rtb-cli-bin Same rule, for the binary
anyhow thiserror plus miette is the error surface for the whole toolkit
openssl-sys, native-tls No native TLS stack in this graph

cargo deny also enforces a licence allowlist (MIT, MIT-0, Apache-2.0 (with and without the LLVM exception), BSD-2-Clause, BSD-3-Clause, ISC, Unicode-DFS-2016, Unicode-3.0, Zlib, CC0-1.0, MPL-2.0 and 0BSD) and denies yanked crates, wildcard version requirements, and any source other than crates.io.

deny.toml waives no advisories.

Lint policy

Setting Level Where
unsafe_code deny at the package level, forbid in src/lib.rs Cargo.toml, src/lib.rs
missing_docs warn Cargo.toml
clippy::pedantic, clippy::nursery, clippy::cargo warn Cargo.toml

unsafe_code is deny rather than forbid at the package level specifically so an individual test file can #![allow(...)] when it genuinely needs to; the library itself carries #![forbid(unsafe_code)], and that is the guarantee that ships.

Four clippy lints are switched off: module_name_repetitions, missing_errors_doc, missing_panics_doc and multiple_crate_versions.

CI runs cargo clippy --all-targets -- -D warnings, so every one of those warn levels is an error in the pipeline.

Toolchain and MSRV

rust-toolchain.toml pins an exact stable release in its channel field, with rustfmt, clippy and rust-src. Renovate moves that pin in its own merge request. It is exact rather than the floating stable channel because clippy runs with -D warnings, and a new stable release can add or tighten lints: on a floating channel that turns the pipeline red with no source change, where a pinned one lets the new findings be fixed in the same reviewable change as the bump.

Note that this is not the MSRV. Cargo.toml declares rust-version = "1.85", the highest rust-version in the dependency graph (unicode-segmentation 1.13.3 sets it). Every CI job builds on the pinned toolchain, which is far newer, so CI never compiles the crate on 1.85. It was checked by hand with cargo +1.85 check when the number was set; a dependency bump can raise the floor without CI noticing.

Running the checks locally

just targets, from the justfile:

Target Command it runs
just check (default) cargo check --all-targets
just build cargo build --all-targets
just fmt / just fmt-check cargo fmt --all / --check
just lint cargo clippy --all-targets -- -D warnings
just test cargo nextest run, falling back to cargo test
just audit cargo deny check
just docs cargo doc --no-deps with RUSTDOCFLAGS="-D warnings"
just site-build / just site-serve zensical build --clean / zensical serve
just ci fmt-check, lint, docs, test, audit in that order

just ci is the local mirror of the merge-request gate. The docs site build is not part of it: the site is built and deployed from main by a separate pipeline job, so a docs change is not gated on the site compiling. Run just site-build yourself before raising a docs merge request.

All tests run headless. None of them need a TTY, and none of them talk to the network.

Releases

Releases are cut by colophon from Conventional Commits. Pushing to main opens or updates a release merge request; merging that MR creates the tag and the release, and the tag's pipeline publishes the crate to crates.io. Tags are named rtb-tui-v<version> even though this is a single-crate repository, for consistency with the other phpboyscout/rust repos and with the tags the monorepo already carries.

Do not tag manually, and do not run cargo update as part of a release. colophon changes only the version in Cargo.toml and Cargo.lock, so dependency churn goes through CI as its own change.