MassBank / RMassBank

Playground for experiments on the official http://bioconductor.org/packages/devel/bioc/html/RMassBank.html
Other
12 stars 15 forks source link

General log wrapper function #287

Closed tsufz closed 3 years ago

tsufz commented 3 years ago

Hi all, It would be appreciated, if we start to develop a general log wrapper function. @pstahlhofen is now working on #232 and #255 and thus any kind of a logging needs to be implemented anyway.

I suggest a general wrapper function in the backend, which:

  1. Generates a general log file in the project folder, e.g. RMassBank.log
  2. Handles log requests by other functions
  3. Appends the log to the log files if requested.

We should handle the logs comprehensive, but simple. For example:

timestamp [Label] [Function/State] [Accession] message

The labels could be something like c("QA/QC", "Error", ...). The function/state tag can be more or less useful freetext and the message anyway.

The wrapper function is then something like:

log_function <- function(label, state, accession, message) {}

label, state, message: obligatory accession: optional

Best wishes, Tobi

meowcat commented 3 years ago

Hi,

Good idea. I would suggest reusing an existing system; I use logger (which is glue-based) in other projects. By default it logs to console, but there is log_appender(appender_file('filename')). https://github.com/daroczig/logger There is also futile.logger and others also mentioned on loggers github page.

As for label I would suggest to use the classical levels: TRACE, DEBUG, SUCCESS, INFO, WARNING, ERROR, FATAL

A log_function might wrap logger to provide a RMassBank-wide unified scheme. In another project I use (but that's an R6 class)

      # [...]
      log_level = function(level, message) {
         message <- glue(message, .envir = parent.frame())
         log_level(level, "{self$name}: {message}")
      },
      # [...]
tsufz commented 3 years ago

I agree with the suggestions of @meowcat. Indeed, we should use the classical levels. Did not remind that. I would prefer the appender solution as logging is not required in all cases, and it should be informative rather than overwhelming the users :-).

tsufz commented 3 years ago

Close with #291