pretty-env-logger

pretty-env-logger is a thin wrapper around the widely used env_logger crate that Rust developers reach for when they want readable console logs without writing custom formatting logic. It reads the same RUST_LOG environment variable env_logger accepts, so existing filter syntax and module-level log level configuration work unchanged, but log lines are rendered with color-coded severity labels and aligned module targets instead of the plain default format.

The crate exposes both a zero-configuration init() entry point and lower-level builder functions (formatted_builder(), formatted_timed_builder()) for teams that want to customize output further, such as writing to stdout instead of stderr or layering in extra env_logger filters. Because it only formats output rather than replacing env_logger’s filtering engine, it stays compatible with any code already instrumented against the standard log crate macros.

What You Get

• Colored severity levels - TRACE/DEBUG/INFO/WARN/ERROR each render in a distinct terminal color for fast visual scanning.
• Aligned module targets - log lines pad the module path column so messages line up regardless of target name length.
• Drop-in env_logger compatibility - reads the same RUST_LOG environment variable and filter syntax, so existing configuration keeps working.
• Customizable builder API - formatted_builder() and formatted_timed_builder() return a standard env_logger::Builder for further tuning, such as output target or extra filters.
• Timestamped variant - init_timed() and formatted_timed_builder() add millisecond timestamps to each log line without extra setup.

Common Use Cases

• Local development debugging - developers set RUST_LOG=trace during cargo run to get colored, readable traces instead of env_logger’s plain default.
• CLI tool output - command-line utilities call pretty_env_logger::init() to give users clear, colorized status and error messages.
• Server request logging - web services log request-handling info with module-level color coding to distinguish subsystems at a glance.
• Custom logging pipelines - projects call formatted_builder() to get a pre-styled Builder, then add their own filters or output targets before calling init().

Under The Hood

Architecture pretty-env-logger is a single-file crate (src/lib.rs) that wraps rather than replaces env_logger’s Builder: its public functions (init, init_timed, init_custom_env, and their try_ counterparts) construct a Builder via formatted_builder() or formatted_timed_builder(), attach a custom format() closure that reads RUST_LOG-style filters, and hand control back to env_logger for the actual filtering and writing. The only mutable state is a single global AtomicUsize (MAX_MODULE_WIDTH) that widens as new log targets are seen, used by a private Padded<T> Display wrapper to keep the module-name column aligned across log lines. There’s no internal layering or dependency injection because the crate does one job — decorate env_logger’s output — and every public entry point funnels through the same two builder constructors, so extending the format only means editing those two closures.

Tech Stack The crate targets stable Rust and depends on exactly two external crates: env_logger (re-exported publicly so consumers get compatible Builder and fmt types) and log, for the Level enum and logging macros. There’s no async runtime, no I/O layer of its own, and no build step beyond cargo — CI cross-compiles and tests the crate across a large matrix of Windows, macOS, and Linux/cross targets on stable, beta, and nightly, and separately runs cargo fmt —check and cargo clippy — -D warnings as gates. It’s published to crates.io and consumed purely as a Cargo dependency, not a service or CLI itself.

Code Quality There are no unit tests in the crate itself, even though CI’s cargo test steps run against the full target matrix — verification is effectively left to the four example binaries under examples/, which double as manual checks of colored output rather than assertions. Code quality is instead enforced through Rust’s type system, a deny(missing_docs) lint (every public item carries a doc comment, which the crate does consistently), and CI-gated rustfmt/clippy checks. Error handling is minimal but explicit: init() and init_timed() call unwrap() on the underlying SetLoggerError, while try_init() and try_init_timed() surface the Result directly for callers who want to handle a second-initialization attempt themselves rather than panic.

API Design The public API is deliberately small and mirrors env_logger’s own naming (init, init_custom_env, try_init) so anyone familiar with env_logger can adopt pretty-env-logger by changing an import and a Cargo.toml line — the whole integration for the common case is one init() call. Power users get an escape hatch via formatted_builder() and formatted_timed_builder(), which return a standard env_logger::Builder pre-loaded with the colored format function, so any further customization uses the same builder API env_logger already documents rather than a new bespoke config surface. There’s nothing conceptually novel here — it’s a focused formatting convenience — but the near-zero boilerplate and close API mirroring of a widely used crate make it low-friction to add and easy to remove later.