Closed MisterDA closed 2 years ago
As per level semantics, the info level is for getting more information about how the program operates. It's not meant to be output by default. This PR would also break the convention established by this cli interface that adding -v
increases verbosity, and that it does so in two steps, info and debug.
The more programs behave the same way, the better.
If you think it's justified for you to walk away from that convention, just define your own option.
Fair enough, thanks for the explanation.
I'm adding support to several tools using logs and fmt of the tty, colors, and verbosity integration with cmdliner, fmt, and logs. Some of these tools were defaulting to the info error level (instead of
Logs_cli
default toSome Logs.Warning
). It is tricky to keep that behavior withLogs_cli.level
because it doesn't return whether the error level was set by the user or defaulted toSome Logs.Warning
. The suggested workaround to useenv
seem to indicate that I could set that parameter, test the existence of the env var, do aputenv
if it isn't set, and then callLogs_cli.level
. Maybe I've missed something, but an easy and nice way is to add an optionaldefault
parameter (that still defaults toSome Logs.Warning
) toLogs_cli.level
. UsingLogs.level_to_string default
also allows the help page to report the app chosen default level.