## check if other logger packages are available and exit if not for (pkg in c('devtools')) { if (!requireNamespace(pkg, quietly = TRUE)) { warning(paste(pkg, 'package not available, so cannot build this vignette')) knitr::knit_exit() } }
knitr::opts_chunk$set( collapse = TRUE, comment = "#>" )
In this vignette I suppose that you are already familiar with Customizing the format and destination of log records vignette, especially with the Log namespaces section.
So that your R package's users can suppress (or render with custom layout) the log messages triggered by your R package, it's wise to record all those log messages in a custom namespace. By default, if you are calling the ?log_level
function family from an R package after importing from the logger
package, then logger
will try to auto-guess the calling R package name and use that as the default namespace, see eg:
library(logger) devtools::load_all(system.file('demo-packages/logger-tester-package', package = 'logger')) logger_tester_function(INFO, 'hi from tester package')
But if auto-guessing is not your style, then feel free to set your custom namespace (eg the name of your package) in all ?log_info
etc function calls and let your users know about how to suppress / reformat / redirect your log messages via ?log_threshold
, ?log_layout
, ?log_appender
.
Please note that setting the formatter function via ?log_formatter
should not be left to the R package end-users, as the log message formatter is specific to your logging calls, so that should be decided by the R package author. Feel free to pick any formatter function (eg glue
, sprintf
, paste
or something else), and set that via ?log_formatter
when your R package is loaded. All other parameters of your logger
will inherit from the global
namespace -- set by your R package's end user.
Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.