logging levels now override CLI setting by config file

[bertsky]

Since #164 and v0.8 (with CONFIG_PATHS in core/ocrd/logging.py), the log level set via command line parameter (e.g. "-l DEBUG") can get overriden by settings in those config files. I think it should be the other way round.

[kba]

Setting the log level via command line switch does this:

logging.getLogger('').setLevel(logging.getLevelName(value))

It sets the (minimum) log level for the root logger. More specific rules in the ocrd_logging.py files will override this.

What do you mean by "the other way round"? Do you want the log level specified on the command line override all loggers? That would defeat the purpose of the ocrd_logging.py override mechanism. And it's kinda difficult because loggers get created at runtime.

Couldn't you just disable the customizations in the ocrd_logging.py that override the root logger settings?

[bertsky]

If I set the log level via command line switch it will affect all loggers (e.g. DEBUG) – this is to be expected.

But the specific rules in ocrd_logging.py files will be unaffected by that CLI setting (e.g. stay at WARN) – this goes against the general principle; command line should always have precedence over config files.

[kba]

I understand what you're saying but I still don't understand why you're using both mechanisms (command line and config file). Yes, CLI params should override config file default but not more specific rules. Minimum level for a specific logger namespace prefix, should override the generic rule.

If I set the log level via command line switch it will affect all loggers (e.g. DEBUG) – this is to be expected.

No, it will affect the root logger. The config file is parsed afterwards and its more specific rules overrride the root logger.

Don't get me wrong, it would be fun to implement this (overriding getLogger probably to enforce a global loglevel) but I'm not sure that it is a better convention. What if you want to want DEBUG statements but only WARN and above from PIL (which is quite spammy)? Or you generally want only ERROR but debug ocrd.asv.aligner.* specifically?

[bertsky]

I understand what you're saying but I still don't understand why you're using both mechanisms (command line and config file). Yes, CLI params should override config file default but not more specific rules.

Here I disagree. If the CLI is defined such that specifics are impossible to articulate, so be it: it is a last resort then. Why not have a (coarse but effective) last resort at CLI and a (more refined but elaborate) configuration facility? (Isn't this what cfg vs cli is all about after all?) (Of course, one could define the CLI differently, like applying loglevel only to the top processor's logger, or by adding another parameter for the name of the logger to be changed.)

Minimum level for a specific logger namespace prefix should override the generic rule.

True for everything between defaults in code and any config files. But having an override mechanism above those only makes sense if it actually overrides them.

> If I set the log level via command line switch it will affect all loggers (e.g. DEBUG) – this is to be expected. No, it will affect the root logger. The config file is parsed afterwards and its more specific rules overrride the root logger.

That's strange. I was merely describing my observation there. If I use "-l DEBUG" I get debug level messages from all loggers (`ocrd.resolver`, `ocrd.processor`, `ocrd.workspace` etc). Otherwise I only get info level messages. Is that not intentional?

Couldn't you just disable the customizations in the `ocrd_logging.py` that override the root logger settings?

I only have customizations for a specific logger in my `ocrd_logging.py`. That logger I cannot control via CLI anymore, which I believed was not only unintentional but unintuitive.

Don't get me wrong, it would be fun to implement this (overriding `getLogger` probably to enforce a global loglevel) but I'm not sure that it is a better convention.

My concern is with a good convention, too. But are you sure global loglevel via CLI can only be implemented by overriding `getLogger`? How about using a `StreamHandler` for all STDERR logging and applying the CLI's setLevel() to that _handler_ instead of the root _logger_? (Another `FileHandler` or `HTTPHandler` or `SMTPHandler` could ensure logs of a certain level are always kept somewhere persistently, regardless of the CLI setting.)

What if you want `DEBUG` statements but only `WARN` and above from `PIL` (which is quite spammy)?

Interesting. One would have to enumerate all other loggers via config file, or indeed need overriding `getLogger`. But how about setting `logging.basicConfig(level=logging.DEBUG)` via config file then? (For that to work, the existing call of `basicConfig()` in _ocrd/logging.py_ needed to be moved below executing config files though, because repeated calls are ignored.)

Or you generally want only `ERROR` but debug `ocrd.asv.aligner.*` specifically?

Same story, yes. My use case was having `WARN` (instead of `INFO` default) configured for spammy loggers via config, but sometimes override _everything_ to `DEBUG` via CLI (to trace an error to its source). So this is opt-in, whereas yours are opt-out.

[kba]

You are right that the current behavior of the command line flag is trivial to implement with a configuration file.

The main reason for focussing exclusively on loggers as opposed to handlers is that we assume all logging happens to the terminal (c.f. https://ocr-d.github.io/cli#logging). In a python-only setup we could use the full power of the python logging module including different handlers (and you can by using this ocrd_logging.py convention for core-based code). However, the CLI spec should be language-agnostic, e.g. also work for shell/CPP/Java implementations which might use different logging mechanisms.

You make a good point for the CLI flag being used as a last resort though. If I set the log level on the command line, it's probably to get more verbose output or no logging output at all, globally, so it makes sense to have it override the config file rules instead of vice versa.

Maybe @VolkerHartmann can offer his opinion here? If it's okay with him, I'll revise the logging as you proposed.

[bertsky]

Glad we got that discussion started ;-)

Just one more remark on implementation: I am afraid my proposal using an explicit StreamHandler for CLI's setLevel() does not in fact give the desired behaviour. Maybe there is another simple way though, perhaps utilizing loglevel NOTSET more directly…

[VolkerHartmann]

In my opinion cli parameters overwrites all other settings.
Usually you will configure special log levels for troubleshooting, which you then deactivate via --parameter WARN (or ERROR) to speed up the process again.
But it's never used to make a fine grained analysis via --parameter TRACE which will take you to logging hell.
Handlers won't be affected by this switch. There should be always a default configuration which writes all warnings and errors to stdout/stderr.