pimalaya_cli/lib.rs
1#![cfg_attr(docsrs, feature(doc_cfg))]
2
3//! Shared building blocks for the Pimalaya command-line tools.
4//! Published for internal Pimalaya usage: the API follows the needs of
5//! its consumers (himalaya, neverest, cardamum, calendula and friends)
6//! and may change without notice. Third parties should treat it as
7//! private; the io-* protocol crates and pimalaya-stream are the
8//! supported surface.
9//!
10//! This crate factors out the pieces every Pimalaya CLI would
11//! otherwise reimplement: argument parsing glue, output rendering,
12//! logging and interactive prompts. Each piece sits behind its own
13//! cargo feature, so a binary pulls in only what it uses.
14//!
15//! Unlike the io-* protocol libraries this crate is deliberately std:
16//! it exists to talk to a terminal, a filesystem and a human, so it
17//! never targets no_std.
18//!
19//! The clap module wires shared arguments and the completion, manual
20//! and JSON Schema commands into a binary's parser. The printer and error
21//! modules render command output, events and failures to stdout, the
22//! output module holds the shapes every binary shares (bytes, pages),
23//! and the log module initializes the logger.
24//!
25//! Text output is plain text: no border, no colour, nothing sized to the
26//! terminal. The fields module lays a record out as aligned `Label: value`
27//! lines, the columns module a list as aligned columns under a header,
28//! and the sanitize module defuses untrusted text before either prints
29//! it.
30//!
31//! A binary has no setup wizard: on a first run, the welcome module tells
32//! a person which configuration file is missing and prints the commands
33//! creating it from the sample shipped next to the binary, then the first
34//! command to run. The shell module quotes such commands for a paste.
35//!
36//! A binary keeping one account open across commands runs a session over
37//! its stdin: the repl module reads one command per line with the
38//! binary's own grammar, the mcp module answers Model Context Protocol
39//! requests, its tools derived from that grammar or written by hand, and
40//! the session module keeps the commands they run off stdin.
41//!
42//! The prompt and spinner modules handle interactive input and progress.
43//! The build module exposes helpers for build scripts.
44
45#[cfg(feature = "build")]
46pub mod build;
47#[cfg(feature = "terminal")]
48pub mod clap;
49#[cfg(feature = "terminal")]
50pub mod columns;
51#[cfg(feature = "terminal")]
52pub mod error;
53#[cfg(feature = "terminal")]
54pub mod fields;
55#[cfg(feature = "terminal")]
56pub mod log;
57#[cfg(feature = "mcp")]
58pub mod mcp;
59#[cfg(feature = "terminal")]
60pub mod output;
61#[cfg(feature = "terminal")]
62pub mod printer;
63#[cfg(feature = "prompt")]
64pub mod prompt;
65#[cfg(feature = "repl")]
66pub mod repl;
67#[cfg(feature = "terminal")]
68pub mod sanitize;
69#[cfg(any(feature = "repl", feature = "mcp"))]
70pub mod session;
71#[cfg(feature = "terminal")]
72pub mod shell;
73#[cfg(feature = "spinner")]
74pub mod spinner;
75#[cfg(feature = "terminal")]
76pub mod welcome;