New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: log to stderr not stdout [might not take this one] #60
Conversation
Motivation: Logging to stderr makes more sense as it enables command line utilities to log. Modifications: Log to stderr, not stdout Result: more useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the introduction of the two but I'm not sure if stderr should be the default one to print to 🤔
Do you think stdout should be default? What about command line utilities like
? |
Yeah that may be a good point... It's one of those things where there's no "best" default I guess though... If you prefer stderr and people agree then should be fine 👍 I also skimmed for some prior art. Results are "it's a mix" 😉 (skimmed java defaults (default stderr, though most popular lib defaults to stdout, configurable; rust has a million mini libs which all do differently, no clear "by default ..."). |
Hehe, yes, nobody knows. I guess the best argument for |
I’m a fan of |
/// Ships with the logging module, really boring just prints something using the `print` function | ||
internal struct StdoutLogHandler: LogHandler { | ||
internal struct StderrLogHandler: LogHandler { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
=> i suggest we take an enum here to allow the user the choose between stdout and stderr
=> as for default, its a good question!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tomerd sure, could do that. StdioLogHandler(stream: StdioLogHandler.Stream)
with enum Stream { case stdout; case stderr }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I like it. Default: dunno :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets keep the default stdout, CLIs can fairly easily switch to stderr with this design
yes |
Expose `StreamLogHandler` to the public which replaces the previously internal `StdoutLogHandlers`. Users can choose now the output stream, while `stdout` is the default. ### Motivation: As discussed on #51 and #60 ### Modifications: Rename `StdoutLogHandler` to `StreamLogHandler` and provide 2 factory methods `standardOutput(label:)` and `standardError(label:)` for using during bootstrapping. ### Result: Users who adopt other logging backends during `LoggingSystem` bootstrapping will still be able to use the default log handler to get very basic console output to their choice of `stdout` or `stderr`. ### Example: ``` // Log to both stderr and stdout for good measure LoggingSystem.bootstrap { MultiplexLogHandler([ FancyLoggingBackend(label: $0), StreamLogHandler.standardError(label: $0), StreamLogHandler.standardOutput(label: $0) ]) } ```
Motivation:
Logging to stderr makes more sense as it enables command line utilities
to log.
Modifications:
Log to stderr, not stdout
Result:
more useful