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 of short rows as aligned columns under
28//! a header, the listing module frames a list with the fields placing it and
29//! the errors of its items, the account module prints the accounts and
30//! whether their backends answer, the capability module what an account
31//! serves, the records module a list of wide items the way `git log`
32//! prints commits, and the sanitize module defuses untrusted text before
33//! any of them prints it.
34//!
35//! A binary has no setup wizard: on a first run, the welcome module tells
36//! a person which configuration file is missing and prints the commands
37//! creating it from the sample shipped next to the binary, then the first
38//! command to run. The shell module quotes such commands for a paste.
39//!
40//! A binary keeping one account open across commands runs a session over
41//! its stdin: the repl module reads one command per line with the
42//! binary's own grammar, the mcp module answers Model Context Protocol
43//! requests, its tools derived from that grammar or written by hand, and
44//! the session module keeps the commands they run off stdin.
45//!
46//! The prompt and spinner modules handle interactive input and progress,
47//! and the signal module the termination signals a long-lived command
48//! stops cleanly on.
49//! The build module exposes helpers for build scripts.
50
51#[cfg(feature = "terminal")]
52pub mod account;
53#[cfg(feature = "build")]
54pub mod build;
55#[cfg(feature = "terminal")]
56pub mod capability;
57#[cfg(feature = "terminal")]
58pub mod clap;
59#[cfg(feature = "terminal")]
60pub mod columns;
61#[cfg(feature = "terminal")]
62pub mod error;
63#[cfg(feature = "terminal")]
64pub mod fields;
65#[cfg(feature = "terminal")]
66pub mod listing;
67#[cfg(feature = "terminal")]
68pub mod log;
69#[cfg(feature = "mcp")]
70pub mod mcp;
71#[cfg(feature = "terminal")]
72pub mod output;
73#[cfg(feature = "terminal")]
74pub mod printer;
75#[cfg(feature = "prompt")]
76pub mod prompt;
77#[cfg(feature = "terminal")]
78pub mod records;
79#[cfg(feature = "repl")]
80pub mod repl;
81#[cfg(feature = "terminal")]
82pub mod sanitize;
83#[cfg(any(feature = "repl", feature = "mcp"))]
84pub mod session;
85#[cfg(feature = "terminal")]
86pub mod shell;
87#[cfg(feature = "signal")]
88pub mod signal;
89#[cfg(feature = "spinner")]
90pub mod spinner;
91#[cfg(feature = "terminal")]
92pub mod welcome;