Skip to main content

Crate larust_core

Crate larust_core 

Source
Expand description

Application bootstrap: config loading, logging, and the Axum server.

Re-exports axum so generated Larust applications don’t need to depend on it directly for router/type access. tokio cannot be re-exported the same way because #[tokio::main]’s macro expansion requires tokio to be a directly resolvable crate name at the call site.

Re-exports§

pub use axum;

Structs§

AppPaths
Canonical locations belonging to one Larust application.
AppState
Explicit, clonable application state for code that should not depend on Larust’s legacy process-wide helper facades.
Application
Config
ErrorPages
Rendered once (at Application::with_error_pages call time, not per request) and cached as plain Strings rather than a render closure or a larust_view::View - these pages have no per-request dynamic content (no session, no user), and this crate has no dependency on the view engine at all (see Cargo.toml), so there’s nothing a closure would buy over pre-rendering once.
GracefulShutdown
Configuration for crate::Application::with_graceful_shutdown - opt-in: an Application that never calls that method keeps today’s exact behavior (a bare axum::serve that exits the instant Ctrl+C is pressed). Flipping every existing app’s shutdown behavior silently would be exactly the kind of surprise a framework upgrade shouldn’t introduce.

Enums§

AppError
The framework’s primary error type.

Functions§

config
Returns the process-wide config Application::new() already loaded - the same OnceLock-backed idiom larust_orm::pool() uses for the connection pool. Unlike pool(), this panics rather than returning a Result if called before Application::new(): every Larust entry point calls Application::new() as its first line (there’s no analogue to pool()’s “forgot to call connect() later” scenario - nothing before Application::new() could plausibly need config at all), so treating this as a real caller-contract violation (like abort()’s own documented panic for an invalid status code) rather than a Result every call site would need to unwrap anyway is the better fit here.
default_internal_html
The framework’s own built-in 500 page. Production-mode only - debug mode (APP_DEBUG=true) never reaches this; see error::debug_page.
default_not_found_html
The framework’s own built-in 404 page - styled to match the demo app’s branding (see page_shell’s own doc comment for the exact source of the color tokens/copy this mirrors).
resolve_app_root
Overrides the compile-time-baked app root a generated app’s own paths() function would otherwise always use unconditionally (env!("CARGO_MANIFEST_DIR"), fixed at cargo build time to wherever the build happened to run) - the identical xr upgrade/ LARUST_CHECKOUT_ROOT pattern (see that command’s own resolve_checkout_root), applied here for the same reason: “baked in” doesn’t survive every real scenario. Without this, a binary built on one machine (a CI runner, a dev box) and then copied to a different directory on whatever actually serves it - rather than built in place there, the way xr deploy does it today - would still look for .env/ storage//database/ at the build machine’s own path, not wherever it actually ended up. Set LARUST_APP_ROOT as a real process environment variable (e.g. a systemd unit’s own Environment=LARUST_APP_ROOT=... line) to unlock exactly that - a minimal deployment needing nothing but the compiled binary and an .env file sitting next to wherever it’s actually run from.
try_config
config()’s non-panicking twin, for the rare caller that has a sensible fallback behavior for “no Application::new() has run yet” rather than treating it as a contract violation - e.g. larust_http::session’s cookie-name derivation, which needs to behave identically whether or not the specific test harness building a router happened to construct an Application first.
try_paths
Returns the process-wide paths Application::new() already published - None if no Application has been constructed yet in this process (every narrow test harness that builds a session-bearing router directly off a bare pool, with no Application::new() call anywhere in the test, hits this case - see larust_http::session::session_layer’s own doc comment for why that’s handled gracefully rather than treated as a contract violation, the identical shape try_config() already has).