Is error the right default?

[epage]

Right now, only errors are shown by default.

I would assume at least warnings would show up. Probably also info(rmational) messages.

Of course, this requires adding a way to make things quieter (which we might need already, see #9). We'd probably need a --quiet / -q flag to go the other way.

[yoshuawuyts]

We'd probably need a --quiet / -q flag to go the other way.

Sounds reasonable.

Right now, only errors are shown by default.

Personally I'd expect anything up to log level info to show up by default. I feel that's how git(1), cargo(1) and chrome's console work too.

[chrysn]

I think that there is no right default log level for all applications (but do think that "error" is only rarely a good default), and it might make sense to have that configurable by the application (eg. using a type parameter).

For cargo and other do-many-things tools, chatting along their actions (which is what "info" is commonly used for) is probably a good idea and default; single action Unix tools might rather follow the rule of silence.

[pksunkara]

I would suggest closing this as resolved. The -q is helpful and error is okay as default level.

[epage]

Yes, since this was opened

• We've added -q
• We've made the default configurable

I am curious why you say "error is okay as default level."

Granted, where I'm coming from for this is that I have historically used logging as my way of sending messages to my users in CLIs which is why "info" was important for my use case. I've started to shift away from that but I could still see warnings being shown by default

[Zykino]

I think UNIX philosophy would say error or even no log is the correct default. But newer clis are quite a lot verbose cargo, npm are like at info level?

It depends on the tool, its intended users, …
So I think anything from error to info are a good default, now that it is configurable, -q and -v exist. The developer and user can customize their preferred behavior as needed.

[pitoniak32]

I was hoping to be able to have this default to Off :/ I took a look at the code to see why there wasn't an option already, and took a stab at adding the option myself.

And there is no Off option for log::Level. In my cli, I want these formatted logs to be exclusively only shown to the user if the -v flag is given, any info that the user would need to see in general would be through !println or eprintln!.

Is there any way to achieve this type of functionality?

My failed attempt:

#[derive(Debug)]
pub struct OffLevel;

impl LogLevel for OffLevel {
    fn default() -> Option<tracing_log::log::Level> {
        Some(tracing_log::log::Level::)
    }
}

[pitoniak32]

I was hoping to be able to have this default to Off :/ I took a look at the code to see why there wasn't an option already, and took a stab at adding the option myself.

And there is no Off option for log::Level. In my cli, I want these formatted logs to be exclusively only shown to the user if the -v flag is given, any info that the user would need to see in general would be through !println or eprintln!.

Is there any way to achieve this type of functionality?

My failed attempt:

#[derive(Debug)]
pub struct OffLevel;

impl LogLevel for OffLevel {
    fn default() -> Option<tracing_log::log::Level> {
        Some(tracing_log::log::Level::)
    }
}

Right after I posted this I looked deeper at the code and figured it out! If you are welcome to contributions I could add this to the library to allow defaulting to off?

#[derive(Args, Debug)]
pub struct SharedArgs {
    #[clap(flatten)]
    pub verbosity: clap_verbosity_flag::Verbosity<OffLevel>,
}

#[derive(Debug)]
pub struct OffLevel;

impl LogLevel for OffLevel {
    fn default() -> Option<tracing_log::log::Level> {
       None 
    }
}

[pitoniak32]

In addition to this, I would also like to add to the docs on how to change the default level, it wasn't immediately clear to me how to do this, it took some digging

[pksunkara]

If you are welcome to contributions I could add this to the library to allow defaulting to off?

While we would welcome the contribution, we need to discuss whether having a q argument makes sense for the CLI author if they want to default to OffLevel. But we can discuss this on the PR you make.

I would also like to add to the docs on how to change the default level

You can also customize the default logging level:

There's this sentence directly on the main page of docs and in README. Not sure, what else you mean by this. But you can make a PR and I can review it.

[epage]

To help in supporting an OffLevel, we could do add the following attributes to quiet

• value_parser that is assigned to a function that conditionally returns UnknownArgumentValueParser when L::default().is_none()
• hide(L::default().is_none())

[epage]

quiet might also be helpful to overriding -vs that are already present, whether for hitting the up arrow and running again or if you have the command behind an alias.

[pitoniak32]

I opened a pr #95 for adding the OffLevel, in addition to DebugLevel, TraceLevel so all the options are available. I also added a simple example of changing the default Level.

There's this sentence directly on the main page of docs and in README. Not sure, what else you mean by this. But you can make a PR and I can review it.

@pksunkara I saw this sentence, I'm not entirely sure what I was expecting the way to do this to be, but seeing this example just didn't click. I added an example to make it extremely obvious comparing to the default behavior 🙏🏼.

I saw there were some suggestions around the -q flag behavior and if it should be available with the default level to off, personally, for my cli I wouldn't mind if this flag was still present. But I see it could make sense to remove for possible confusion.

Maybe I could just make my example more tailored to adding your own level by implementing the LogLevel trait? And then users can add their own levels if they need Off, Debug, or Trace?