0

Problem

I'm working on a custom package and have run into an interesting edge case in which I need certain code to execute only when it's actually being run by users, rather than when it's triggered during development (e.g. by devtools::check, testthat functions, R CMD CHECK, etc).

Context

I developed custom logging within my package - certain functions, when executed by users, will create a log entry in an external database. I've got this working (with a mix of SQL Server db, and stored procedures). However, the problem is that too much logging occurs during package development. All the various testing/checking/build calls done by an R package developer "pollutes" the database.

So what I need is to be able to modify my logging calls to skip if the call stack is related to devtools/testthat/etc scenarios. How do I do this?

My attempt at troubleshooting

To troubleshoot so far, I created a sample package with these 2 files and explore the console output

zzz.R:

.onLoad <- function(libname, pkgname) {

  myTestFunction()
}

myTestFunction.R:

myTestFunction= function() {
  print(sys.calls())
}

I'll then explore the call stack to see if I can identify reliable keywords that I can detect during my logging, and skip as needed. Here's an example call stack triggered during devtools::check() enter image description here

mkirzon
  • 413
  • 5
  • 9
  • As an alternative, how about either (1) `getOption(dbLoggr.dosql, default=TRUE)` (where you set it to `FALSE` during dev), or (2) `Sys.getenv("DBLOGGR.DOSQL", unset="true")`. There are ways to determine if a particular function or package is in the current stack trace (see https://stackoverflow.com/a/62747050/3358272 and https://stackoverflow.com/a/63380754/3358272), but they are imperfect. I urge the use of `options` (better yet, formalize it and document it in your package). – r2evans Oct 01 '20 at 18:44
  • 1
    Just experimented with options and I do like that workflow, so thanks @r2evans. But what do you mean by "formalize"? Where do you recommend documenting something like this? – mkirzon Oct 01 '20 at 19:34
  • Actually, I found that when running devtools::check(), the options fails during one particular check - "checking R code for possible problems". It looks like that ran with its own environment so didn't honor my globally set option before running the check. – mkirzon Oct 01 '20 at 19:36
  • 1
    By "formalize" I mean make it user-visible, documented, formally checked and used through any of your package's functions that reach out to the DB. – r2evans Oct 01 '20 at 19:45
  • @r2evans and to add to my 2nd comment above, the same happens with building vignettes during checking and package building. What do you recommend so that the global option is universally honored? – mkirzon Oct 01 '20 at 19:56
  • No, not with what we know, sorry. – r2evans Oct 01 '20 at 20:00

0 Answers0