mikaelmello/inquire: interactive terminal prompts for Rust CLIs

The problem inquire solves for Rust CLI authors

A command line tool that needs a value from a human has two options: parse flags and arguments, or ask. Asking is where most Rust projects stall. Reading a line from stdin gives you a string and nothing else, so every project that wants a chooser, a confirmation or a masked password ends up writing its own escape-sequence handling, its own cursor math and its own error type.

inquire is a library for building interactive prompts on terminals, and it covers the prompt shapes that show up repeatedly in CLI work. The README lists Text for input with built-in autocompletion, Editor for longer text via an external editor, DateSelect for a date picked on an interactive calendar, Select for one option from a list, MultiSelect for an arbitrary number of options, Confirm for yes/no, CustomType for text parsed into a type such as a number or UUID, and Password for secret input. Editor and DateSelect are gated behind feature flags.

The audience is narrow and specific: developers writing Rust command line applications who want the asking step handled by a library rather than by their own terminal code. It is not a widget toolkit and it does not draw a persistent interface. Each prompt is a question, and the prompt returns an answer.

How a prompt runs: rendering, validation and the error path

The architecture visible in the repository is a workspace with three members: inquire, inquire-derive and examples. Terminal drawing is delegated to a backend, and the README states you can choose between crossterm (the default), termion or console. That choice matters if your project already depends on one of them, because it avoids pulling in a second terminal library.

Styling is centralized in a RenderConfig struct. It holds foreground color, background color and attributes such as bold for most prompt components, plus the content of special tokens like prompt prefixes, highlighted-option prefixes and the selected and unselected checkboxes. Rather than passing a config to every prompt, you can call inquire::set_global_render_config once and have it apply to all future prompts.

Validation is the part with the clearest contract. Validators run when the user submits input, and they receive different argument types depending on the prompt: &str, &[ListOption] or NaiveDate are named in the README. The return type is always Result<Validation, CustomUserError>. Return Ok(Validation::Valid) to accept, or Ok(Validation::Invalid) with an ErrorMessage, which is either Default or Custom(String), to reject and show feedback. Returning Err(CustomUserError) makes the prompt itself return Err(InquireError::Custom(CustomUserError)), which is how a validator that performs an HTTP request or a database query reports failure. The README notes validators are typed as a reference to dyn Fn, so both functions and closures work, but the functions cannot hold mutable references. That is a real constraint, not a footnote: a validator that wants to count attempts or cache a lookup has to reach for interior mutability.

A macros feature, on by default, exports shorthand macros for the built-in validators at the root of the library.

Installing inquire and writing a first prompt

The README gives the dependency line directly. Add it under [dependencies] in Cargo.toml, and add feature flags if you need a gated prompt type.

[dependencies]
inquire = "0.9.4"

For a gated prompt, the README shows the same dependency with a feature list, for example date.

inquire = { version = "0.9.4", features = ["date"] }

For a first real use, the repository ships runnable examples rather than a single hello-world. The README gives this command, which runs the expense tracker example from the examples workspace member.

cargo run --example expense_tracker -p inquire-examples

Run it and you get an interactive questionnaire in your terminal, built from the prompt types above. The examples directory also contains per-prompt files such as text_simple.rs, select.rs, multiselect.rs, confirm.rs, password_simple.rs, date.rs, editor.rs, custom_type.rs and render_config.rs, plus form.rs and complex_autocompletion.rs for longer flows. Reading the file for the prompt you intend to use is faster than reading the README, because each example is a working call site.

One practical note: the examples live in their own workspace member with their own Cargo.toml, which is why the run command passes -p inquire-examples.

Where inquire is the wrong tool

inquire asks questions and returns answers. It is not a full-screen TUI framework and the README does not present it as one. If you are building a dashboard, a file browser or anything with persistent panels and a redraw loop, you are outside what this library does, and the prompt-per-question model will fight you.

The validator signature is the second boundary. Because validators are references to dyn Fn and cannot hold mutable references, a validation rule that needs to accumulate state between submissions cannot be written as a plain closure over a mutable local. You either use interior mutability or move that state out of the validator.

There is also a cost in what the library does not decide for you. The README documents error handling through thiserror and a standardized InquireError, but it does not document what happens to a partially completed form when the user aborts, or how prompts behave when stdin is not a terminal. Those are the cases worth checking against the source before you rely on them in a pipeline, because a prompt library is most fragile exactly where a human is not present.

inquire compared with argument parsing and with dialoguer

The nearest alternative in the Rust ecosystem is dialoguer, another library for terminal prompts. The difference in approach is in the configuration and validation model. inquire centralizes appearance in a single RenderConfig object that can be set globally with set_global_render_config, and it fixes the validator contract at Result<Validation, CustomUserError> across prompt types, with a dedicated CustomUserError alias for fallible checks such as HTTP requests or database queries. It also lets you pick the terminal backend among crossterm, termion and console, which is a concrete advantage if your project already depends on one of them.

The other comparison is not a library at all. If your tool only ever needs a few values, clap-style argument parsing plus a config file may be simpler, because it keeps the program non-interactive and scriptable. Interactive prompts are for the case where a human is present and the values cannot be known in advance. Choosing between them is a question about your users, not about code quality.

A third option worth naming is writing the terminal handling yourself. inquire exists because that is tedious, and its value is the accumulated detail in rendering, key handling and error types that you would otherwise reimplement.

Maintenance, upgrades and licence

The repository is not archived. The last push was on 2026-03-02, and the most recent releases listed are v0.9.4 on 2026-02-24, v0.9.3 on 2026-02-06 and v0.9.2 on 2026-01-17. Those dates are close together, and the README's dependency line already points at 0.9.4, so the documented version and the newest release agree.

Upgrade cost is dominated by the 0.x version number. A pre-1.0 crate can change its API in a minor release, so pinning is not optional if you care about reproducible builds. The workspace layout also means inquire and inquire-derive version separately from the examples member, so a change in the derive crate does not necessarily mean a change in the prompt API. CHANGELOG.md sits at the top level and is the place to read before bumping.

The licence is MIT, stated in the repository metadata and shown as a badge in the README. MIT is permissive: it allows use in closed-source software provided the copyright notice and permission notice are included. That is the general shape of the licence, not legal advice for your situation.

Editorial conclusion

Adopt inquire if you are writing a Rust CLI and want typed, validated prompts without assembling a full TUI: the README lists Text, Editor, DateSelect, Select, MultiSelect, Confirm, CustomType and Password, and the validators return a fixed Result<Validation, CustomUserError> shape. Do not adopt it if you need widgets beyond prompts, or if your validators must mutate state, since the README states validators are typed as a reference to dyn Fn and cannot hold mutable references. Before wiring it into a release, verify the feature flags your prompt types require, confirm the terminal backend you want (crossterm, termion or console) and check that the version you pin is the one whose API you read on docs.rs.

Frequently asked questions

Official sources

1. License: MIT
2. mikaelmello/inquire on GitHub
3. Project website
4. README
5. Releases