Wasmtime GitHub notifications bot (Jul 31 2026 at 09:20): Wasmtime GitHub notifications bot (Jul 31 2026 at 09:20):Syedsmaeel opened issue #14032:
Currently, src/bin/wasmtime.rs acts as a minimal glue layer that delegates command execution directly to sub-modules via Wasmtime::parse().execute(). While keeping the entry point lightweight is clean, the binary currently lacks centralized global initialization—such as global environment logging (env_logger / tracing) setup—and custom top-level error formatting/context handling.
Moving these cross-cutting concerns to the top-level binary entry point would provide a more consistent experience across all subcommands (run, compile, serve, etc.) and improve debuggability when CLI commands fail.
Proposed Changes
Global Logging Initialization: Set up logging/tracing once at the start of main() in src/bin/wasmtime.rs before dispatching to subcommands.Enhanced Error Context: Wrap the execution error handling in main() with clearer diagnostic reporting or pretty printing rather than returning a raw wasmtime::Result<()>.
Steps to Reproduce / Motivation
Run a wasmtime subcommand with environment log flags set (e.g., RUST_LOG=debug).Observe that logging setup is handled inconsistently or localized strictly within individual command implementations rather than at the top level binary.
Expected Behavior
The CLI entry point should handle global process initialization (logging/tracing, diagnostic context) before dispatching execution to subcommands.
Wasmtime GitHub notifications bot (Jul 31 2026 at 17:29):alexcrichton commented on issue #14032:
Can you describe a bit more the rationale for this change? For example is logging not enabled in some subcommands? Are you expecting errors look a bit different depending on subcommands?
Wasmtime GitHub notifications bot (Aug 01 2026 at 12:42):Syedsmaeel commented on issue #14032:
Thanks for pointing that out @alexcrichton!
I reviewed the codebase and the logging setup (WASMTIME_LOG) and I see that the logging initialization and error handling are already standardized across the subcommands. My original suggestion was to look at centralized entry point handling but it appears the current architecture is handling this as intended.
You can close this issue if you want. Thanks for review time!
Wasmtime GitHub notifications bot (Aug 01 2026 at 15:18):alexcrichton closed issue #14032:
Currently, src/bin/wasmtime.rs acts as a minimal glue layer that delegates command execution directly to sub-modules via Wasmtime::parse().execute(). While keeping the entry point lightweight is clean, the binary currently lacks centralized global initialization—such as global environment logging (env_logger / tracing) setup—and custom top-level error formatting/context handling.
Moving these cross-cutting concerns to the top-level binary entry point would provide a more consistent experience across all subcommands (run, compile, serve, etc.) and improve debuggability when CLI commands fail.
Proposed Changes
Global Logging Initialization: Set up logging/tracing once at the start of main() in src/bin/wasmtime.rs before dispatching to subcommands.Enhanced Error Context: Wrap the execution error handling in main() with clearer diagnostic reporting or pretty printing rather than returning a raw wasmtime::Result<()>.
Steps to Reproduce / Motivation
Run a wasmtime subcommand with environment log flags set (e.g., RUST_LOG=debug).Observe that logging setup is handled inconsistently or localized strictly within individual command implementations rather than at the top level binary.
Expected Behavior
The CLI entry point should handle global process initialization (logging/tracing, diagnostic context) before dispatching execution to subcommands.
Last updated: Aug 30 2026 at 09:07 UTC