global flags for verbose and debug modes?

[hjoliver]

Currently verbose and debug modes are set by command line flags passed around via function argument lists. This is awkward because these flags are potentially wanted in every source file, and it creates a problem inside functions that have not been passed the flag (and may be several levels down the call stack). It seems to me that setting new global flags in lib/cylc/flags.py would be better way to do this, and a simple change to make.

@matthewrmshin - do you agree (or perhaps have a better suggestion?)?

[matthewrmshin]

Do we currently use these options to configure the logger? I am be thinking in a naive way, but can we not simply use the logger to print extra diagnostic messages at higher verbosity levels?

[hjoliver]

Yes and no. Verbose mode causes extra user-relevant information to be printed to stdout, but directly, not via the logger. Debug mode changes the logger level, and (I think) it may also print extra information to stdout or stderr. It would be nice to handle all output via the logger, but in the early days I couldn't get the standard lib logger to do everything that I wanted it to do (how's it done in Rose - have you rolled your own logger?).

So for the moment - at least until #386 is addressed - we potentially need access to the debug and verbose mode flags in every source file.

[matthewrmshin]

how's it done in Rose - have you rolled your own logger?

Yes. See rose.reporter. Right at the start, we have decided that the standard logger does not do what we want (and is far too complex), so we have written something fairly simple (but flexible enough) to do what we want to do.

[matthewrmshin]

(Cylc is slightly different to Rose, because the core of Cylc is the cylc run daemon, so the logger model should work slightly better. Most Rose CLI utilities have no access to a log file, so the logger model does not work at all.)

[hjoliver]

Indeed.

My original intention (pre daemon mode and run db, of course) was to have useful info for users printed to stdout, and the log was meant to function loosely as the run db does (a lot better!) now. But, as I recall, the std logger can't be configured to print just 'normal' priority messages to stdout ... hence the current separate use of stdout/stderr and the logger.

So ... does this proposal seem a reasonable improvement to the status quo, subject to possible complete overhaul in the future for #386.