simple-eyre

A minimal eyre error handler that prints just the error chain — no backtraces, spans, or extra context.

Library
Cargo
v0.3.1
5stars
MIT OR Apache-2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
18/100Needs Attention
Development Activity0
Maintenance0
Community12
Maturity60
Momentum0

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
50/100Fair
Architecture68
Code Quality45
Innovation30
Learning Curve55

simple-eyre provides the smallest possible eyre::EyreHandler implementation for the eyre error-handling crate. Where eyre’s default handler adds location and backtrace information to every report, simple-eyre strips that down to the bare error chain — the top-level error’s Display output followed by an indented, numbered list of its source() causes, and nothing else.

It’s meant for projects that use eyre::Report as a lightweight Box<dyn Error> replacement but don’t want colored spantraces or backtrace-capture overhead in every binary. Installing the hook is a single simple_eyre::install()? call before any Report is constructed, and the crate re-exports eyre itself so consumers don’t need a separate direct dependency on the underlying crate. Development has since moved into the eyre-rs/eyre monorepo, but the published simple-eyre crate on crates.io still ships this same implementation.

What You Get

  • A drop-in eyre::EyreHandler implementation you install with a single simple_eyre::install()? call
  • Plain-text error chain formatting with sequential Caused by: entries and per-cause indentation via the indenter crate
  • A re-exported eyre module (simple_eyre::eyre) so you don’t need a direct dependency on the underlying eyre crate
  • Zero configuration surface — no feature flags, and no backtrace or spantrace capture to tune

Common Use Cases

  • CLI tools that want eyre’s ergonomic ?-based error propagation without backtrace noise in terminal output
  • Small services or scripts where a compact one-line-per-cause error report is preferable to a verbose backtrace dump
  • Projects migrating off eyre’s default handler to cut binary size or startup overhead from backtrace capture
  • Library authors studying a minimal reference implementation of a custom EyreHandler

Under The Hood

Architecture The entire crate is a single file, src/lib.rs (~120 lines), that implements one integration point: eyre’s EyreHandler trait. A unit struct Handler implements the trait’s debug() method, and the public install() function registers it globally via eyre::set_hook(Box::new(move |_| Box::new(Handler))). There is no internal layering because there is nothing to layer — the crate exists purely as a plugin for eyre’s hook system, so its correctness depends entirely on staying compatible with eyre’s EyreHandler trait signature and hook API; a breaking change there breaks this crate immediately.

Tech Stack Written in Rust 2018 edition with exactly two runtime dependencies: eyre (“0.6.0”), the error-handling crate this extends, and indenter (“0.3.0”), used to indent multi-line cause entries in the debug() output. There’s no build tooling beyond Cargo itself; docs.rs metadata enables all-features documentation builds, and CI (GitHub Actions, actions-rs/cargo) runs cargo check and cargo test (default, all-features, no-default-features) across a matrix of Rust toolchains. Distribution is via crates.io with generated docs on docs.rs.

Code Quality There are no dedicated unit test files — the only executable check is a single doctest embedded in the module-level rustdoc comment (marked should_panic) that exercises install() plus a wrapped eyre! error. CI does run that doctest across three build configurations and a Rust version matrix, which catches API breakage even without real unit tests. The debug() implementation itself handles errors carefully for what it does: it walks the cause chain with std::iter::successors(Some(cause), |e| (*e).source()) and writes explicitly to the Formatter, propagating fmt::Result rather than panicking. Naming is idiomatic Rust (snake_case functions, one clearly named Handler type), but there’s no visible clippy or rustfmt config in the repo.

What Makes It Unique simple-eyre isn’t attempting to be novel — it’s explicitly the minimal counterpoint to eyre’s more elaborate default handler (and to color-eyre’s colored, spantrace-heavy one). Its value is in demonstrating, in well under 150 lines, exactly how little code is required to satisfy the EyreHandler trait, making it as much a reference implementation for anyone writing their own custom eyre handler as it is a production dependency.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search