Allow injection of own logging functions (apart from futile.logger)

[aryoda]

For existing source code with already established logging infrastructure the package should support using logging functions injected from outside.

This opens the package for users that do not want to use futile.logger e. g. for missing features or existing code.

The implementation could be done by

• defining a function signature for each log level function (ERROR, WARN, INFO)
• adding a "register.log.functions" function that allows to inject the external logging functions
• use the futile.logger logging functions by default.

[aryoda]

I think the wide-spread logging framework packages should be supported out-of-the-box (OOTB) without creating a hard package dependency or forcing the tryCatchLog client to install all logging framework packages even when only one of them is used.

A solution could be a weak dependency to all OOTB supported logging frameworks like futile.logger via suggests in the package DESCRIPTION:

https://stackoverflow.com/questions/15771706/package-dependencies-for-r-cmd-check

The default logging framework is determined during package loading then via requires or requireNamespace and can be changed by calling a "selector" function.

To support currently unsupported (or self-developed) logging frameworks the tryCatchLog-internal logging functions that wrap the calls to the active logging framework ("selector" functions) should be exposed via a public API (mainly via a register.log.function).

For details of implementing optional package dependencies via suggests see:
http://r-pkgs.had.co.nz/description.html

[aryoda]

List of known logging frameworks for R:

• logging: logging to console, file, sentry server
• futile.logger: logging to files, console
• logR: transactional logging to databases and email notifications
• loggr: logging to files, console
• logr: logging to files
• dtq: detailed auditing of data.table queries
• logit
• rlogging
• log4r
• logging (same name as another package): Powerful R port of the popular Python logging package.

See also:

https://www.r-bloggers.com/effortless-but-powerful-exception-logging-in-r-loggit-1-0-0-released-on-cran/

[aryoda]

Looking into the available logging packages it seems that only a few packages are available at CRAN and the download statistics shows a clear winner:

# devtools::install_github("metacran/cranlogs")
library(cranlogs)
library(data.table)
res <- cran_downloads(when = "last-month", packages = c("futile.logger", "logging", "logR", "logr", "loggr", "dtq", "loggit", "rlogging", "log4r", "luzlogr"))
setDT(res)
res[, .(.N, downloads = sum(count)), by = .(package)][downloads > 0,][order(-downloads),]

#    package        N downloads
# 1: futile.logger 30     29139
# 2:       logging 30      1751
# 3:         log4r 30       753
# 4:       luzlogr 30       204
# 5:        loggit 30       166

So there are only logging and log4r besides futile.logger which seem to be used broaderly.

I tend to ignore other CRAN loggers and keep tryCatchLog open for non-CRAN logging packages via a generic registration function...

That way I could also "relax" the dependency to futile.logger to "suggests" and use it only as the default logger if the package is installed.

[aryoda]

Implemented in version 1.1.0 via set.logging.functions(). No more hard dependency on futile.logger now. Uses futile.logger if it is installed, otherwise a very basic internal logging function (log2console()).