Configure multiple loggers with yaml

[Fuco1]

I think that configuring only a single logger with yaml is not very usable. Ideally, I'd be able to configure the entire hierarchy with a single yaml file, including the logger names.

I came up with this simple function to do that, maybe we can find a way to integrate it into the package.

Basically, it uses the same format as the current yaml configuration except the additional children keyword which contains the nested loggers. The Logger keyword is omitted and instead the logger name is used directly.

configure_loggers <- function(config, parent_name = NULL) {
    for (i in seq_along(config)) {
        name <- paste(c(parent_name, names(config[i])), collapse = "/")
        value <- config[i][[1]]
        children <- value$children

        value$children <- NULL
        lg_config <- lgr::as_logger_config(list(Logger = value))
        lgr::get_logger(name)$config(lg_config)

        configure_loggers(children, name)
    }
}

Example config:

## loggers.yaml
mypackage:
  threshold: info
  children:
    db:
      threshold: warn
    model:
      threshold: info
      children:
        user:
          threshold: debug

Usage:

configure_loggers(yaml::read_yaml('loggers.yaml'))

[Fuco1]

Actually, now I found out that the config method completely replaces the config, instead of only updating what was supplied. This is mostly my intention as I do some basic default setup in code, but want the yaml config mostly to be used for overloading the settings when debugging or running in different environments.

I've updated the function a big by gutting some lgr internals. Maybe adding an option to config such as use_defaults = FALSE or something would work. But it seems it might involve more changes in the config parsing logic as well.

configure_loggers <- function(config, parent_name = NULL) {
    for (i in seq_along(config)) {
        name <- paste(c(parent_name, names(config[i])), collapse = "/")
        lg <- lgr::get_logger(name)
        value <- config[i][[1]]
        children <- value$children

        value$children <- NULL
        lg_config <- lgr::as_logger_config(list(Logger = value))
        lg_parsed_config <- lgr:::parse_logger_config(lg_config)

        if ("threshold" %in% names(lg_config)) {
            lg$set_threshold(lg_parsed_config$threshold)
        }

        if ("appenders" %in% names(lg_config)) {
            lg$set_appenders(lg_parsed_config$appenders)
        }

        if ("propagate" %in% names(lg_config)) {
            lg$set_propagate(lg_parsed_config$propagate)
        }

        if ("exception_handler" %in% names(lg_config)) {
            lg$set_exception_handler(lg_parsed_config$exception_handler)
        }

        if ("filters" %in% names(lg_config)) {
            lg$set_filters(lg_parsed_config$filters)
        }

        configure_loggers(children, name)
    }
}

[s-fleck]

Thanks for the Input.

Configuring multple loggers

So the yaml config stuff is still kinda experimental and I think at some point I will need to sit down and work through the whole code again. Supporting multiple Loggers seems like a necessary feature, sadly it will probably be a while till I get around to that. If/when I get around to it, I would would probably look something like this though:

- test:
  threshold: info

- "test/child":
  threshold: warning

Adding child loggers via a child: field seems like a logical thing to do, but i fear that this can end up pretty quickly in way to many levels on indentation. The code above avoids that problem, but it's also not completely unthinkable to support both approaches.

Modifying config instead of replacing it

If I remember correctly I tried to implement some version of this in earlier version of lgr, but then abandoned the idea. I don't really remember why, but I think it was because it was too confusing. It should be pretty doable to optionally support this though, something like lg$config(..., keep_existing = TRUE or something)

So in conclusion: I think both suggestions are good, but I'm not sure when I can implement them. The actual code is probably not too hard (probably something very similar to your code examples) but will still require a lot of testing and and API-design choices