nushell: duplicate log level between main binary and the standard library

@fdncred @rgwood 😱 😆

i think i share how @rgwood feels about that 🤔

i do not see std being that much separate from the “core” nushell => more an implementation detail as @rgwood said iirc, especially if we’re mainly moving commands from rust to nushell!

and as is say it, i think more and more that we should only have --log-level on the nu binary and have NU_LOG_LEVEL align on the value given when starting the shell

what follows is that the log format inside std log should align with the current one from the rust implementation 🤔

💡 that can always be changed quite easily as these are only changes from the library and not from core 😉

TL;DR: i would vote for removing the NU_LOG_LEVEL and use the value given by --log-level 😋

Good luck. Pro tip: Don’t put ‘trace’ level entries in your scripts because you’ll never find them with nu --log-level trace.

–log-level for internal interpreter operation,

--log-level is currently used for any Rust logging that uses the log crate. I would not say it’s just for the interpreter.

For me, the only wrinkle is I do not know whether there’s any logging from built in commands. Can anybody say?

Yes: https://github.com/nushell/nushell/blob/d0a83fec693e50fbe38780aaec932f6b8cc8ed0a/crates/nu-system/src/linux.rs#L98-L99

I think we’re going back and forth here because we actually have 2 separate logging functions, controlled by different flags, which log different kinds of operation:

• –log-level for internal interpreter operation,
• the NU_LOG_LEVEL and std log for logging the operation of custom commands (eventually it will be in widespread use, not now, though). We don’t have to conflate them! And considering the different operations they affect, maybe we shouldn’t try?

For me, the only wrinkle is I do not know whether there’s any logging from built in commands. Can anybody say? I would like to be able to say there is just one switch that controls logging for all commands, both custom and built-in, that seems like a clean division of labor.

My use case for the current NU_LOG_LEVEL and std log is this: I want the convention to be that std log info is for verbose progress messages from commands. These are suppressed by default, but can be enabled for a specific invocation. The environment setting prefix is just the ticket for this:

〉def test_logging [] {
::: print "Doing something"
::: log info "verbose message about what I just did"
::: }
〉let-env NU_LOG_LEVEL = WARN    # (currently required because of #8823)
〉test_logging
Doing something
〉NU_LOG_LEVEL=INFO test_logging
Doing something
INF|2023-04-09T12:40:32.644|verbose message about what I just did

The log level could be passed to the stdlib command as a parameter or an environment variable, I think. So maybe NU_LOG_LEVEL would live on as an implementation detail.

this is what i had in mind in the first place i think 👌