Use environment variable to set default level

[zoggy]

Hello,

I use Logs in a lot of my libraries, each one having one or more log sources. When a tool or another library uses other Logs-using libraries, I'd like to be able to set log level for each log source of these libraries.

There are three options, now:

• I can use Logs.Src.set_level on each log source of each library,
• or I can set the same log level for every log source, using Logs.set_level,
• or mix the two ways above.

Setting the same log level is not satisfying, because I may want different log levels on different parts of the software.

Using Logs.Src.set_level on each log source of each library can be done programmatically but if I want to give control to the user, I must use either command line options or environment variables, with an option or an environment variable for each source of each library. This is quite heavy and must be done in each new library or tool using other libraries.

It would be more convenient if, when creating a new log source (with Logs.Src.create), an environment variable name could be provided and, if it is, the default log level for this source would be set according to the value of this environment variable (using Logs.level_of_string).

For example:

let src = Logs.Src.create ~env:"MYPKG_LOG_LEVEL" "mypkg"

would create a new source initialized to the value of environment variable MYPKG_LOG_LEVEL if it is set and has a correct value (i.e. a string corresponding to a log level). If no environment variable name is provided or the value of this variable is incorrect (i.e. it does not correspond to a log level), then the initial log level for the created source would be set as it is now. So this change would not break backward-compatibility.

Regarding the environment variable name, the "_LOG_LEVEL" part could be added automatically to provide consistency between packages. So

let src = Logs.Src.create ~env:"MYPKG" "mypkg"

would honor the MYPKG_LOG_LEVEL environment variable.

I can make a PR if you agree with this improvment.

[dbuenzli]

Related #37

I'm not convinced multiplying individual environment variables is such a good idea. If anything I think I'd rather have a more complex LOG_LEVEL environment variable along the syntax suggested in #37. That way there's a single place I need to set or lookup to indicate or understand how my log levels are going to behave.

[zoggy]

That's fine with me as long as I have a single function in Logs which I can call which retrieves the given env. variable, parse the format and set log source levels accordingly.

[hannesm]

For what it is worth, we have since nearly a decade using https://github.com/mirage/mirage-logs/blob/main/src/mirage_logs_cli.mli (previously tightly integrated into the mirage tool) for this. Note that we don't use environment variables, but maye the syntax or parts of the code are useful for this discussion. Of course once logs has support for this, we'll switch to using that. :)

[zoggy]

Using environment variables (or only one with an ad-hoc syntax) is useful for programs fork/exec-ing: executed programs inherit the log level specification from the environement, without need to pass additional command line options.

[hannesm]

@zoggy to be clear, my intention was not to say "don't use environment variables". My intention was to refer to an existing and used implementation for the syntax. Adding support for reading the same syntax from an environment variable should be straightforward and very welcome. Only in the MirageOS ecosystem we don't have environment variables - that's the reason the linked implementation does not include support for them.