Skip to content
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

Is error the right default? #10

Open
epage opened this issue Jul 25, 2018 · 13 comments
Open

Is error the right default? #10

epage opened this issue Jul 25, 2018 · 13 comments

Comments

@epage
Copy link
Member

epage commented Jul 25, 2018

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
Copy link
Contributor

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
Copy link

chrysn commented May 19, 2019

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
Copy link
Member

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

@epage
Copy link
Member Author

epage commented Apr 17, 2023

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
Copy link

Zykino commented Apr 17, 2023

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.

epage added a commit that referenced this issue Dec 4, 2023
chore(config): migrate renovate config
@pitoniak32
Copy link

pitoniak32 commented Feb 19, 2024

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
Copy link

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
Copy link

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
Copy link
Member

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
Copy link
Member Author

epage commented Feb 19, 2024

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
Copy link
Member Author

epage commented Feb 19, 2024

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
Copy link

pitoniak32 commented Feb 19, 2024

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?

@sebhoss
Copy link

sebhoss commented Sep 11, 2024

If I specify Info to be my default log level, how would a user be able to change that to a less verbose output, e.g. switch back to error? It seems to me that specifying -v (warn) on an app that defaults to info just ignores the -v flag.

Edit: just realized that -q is a counted arg as well, so specifying that reduces the log level - sorry for the noise!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants