Feature: different loggers, --logger and --pretty

[yoshuawuyts]

I was wondering what a good approach would be to enable different loggers for production / development. I can't think of any clean approach for automatic switching, so probably the best way to go about it is to add some switches.

Example: HTTP Proxy

Say we were building an HTTP proxy in Rust, similar to Nginx. We would probably want machine-readable log output for production, but in development we would want something that is optimized for human beings.

Also depending on the organizations involved, different people might want to use different loggers. Some might want to run it through syslog, whereas others might prefer to ingest ndjson from stdin.

Proposal

I propose we add 2 new flags: one for selecting a log formatter, and one for choosing the "pretty printer" formatter.

USAGE:
    main [FLAGS] [OPTIONS]

FLAGS:
    -h, --help         Prints help information
    -V, --version      Prints version information
        --pretty       Log output in a human readable format
    -v, --verbosity    Pass many times for more log output

OPTIONS:
    -o, --output <format>   Control the formatting of the log output

Design Considerations

• I'm not sure if --pretty should have a shorthand. If it does, it should probably be -P (uppercase) to not conflict with the commonly used -p/--port.
• -o/--outfile is also commonly used as a shorthand for which file to write stdout output to. This could potentially conflict with applications that have opinions about where to store artifacts. -l/--logger (or similar) might have fewer potential conflicts, despite not being rooted in prior art (see below).

Prior Art

• Docker log drivers
• journalctl (systemd) --output

Related Discussions

• rust-lang-nursery/cli-wg#12 (Error handling in CLI apps)

Wrapping Up

I hope all of this makes sense. I'd be really curious to hear people's thoughts on this!

[killercup]

I propose we add 2 new flags: one for selecting a log formatter, and one for choosing the "pretty printer" formatter.

Counter proposal: Make a new crate, clap-logger-flag for logger-specific settings.

Why? Because logging setup can get arbitrarily complex and I wouldn't want to end up with a flag that enables journald, logstash, and maybe also sentry. The idea to include env logger was just one for convenience -- we might even want to make this optional.

[yoshuawuyts]

The idea to include env logger was just one for convenience -- we might even want to make this optional.

Could you elaborate? Do you mean this should be a feature flag?

[killercup]

Yeah, putting it behind a feature flag is probably what I'd do. Maybe keep it enabled by default, but also maybe not.

To put this into context and to explain why it may seem that I've changed my mind: This is extracted from quicli. Quicli, however, was written with a very different mindset: "make @killercup happy" in contrast to "be a good crate that makes clap user happy". So, being specific to env logger seemed fine then, but now we are going into a direction where the crate should probably not be as opinionated.

[yoshuawuyts]

We chatted more on IRC, and agreed this crate might not be the best fit. Instead I'll be experimenting in a separate crate with the right abstractions for this.