debugme, package support and datasets

[cipherz]

First, thanks for putting this package together it is nice having the ability to have debug statements in a package with almost no cost. I recently started adding debugme to a package that I am putting together and noticed some issues with package datasets. The issue is that after adding debugme to the package and activating it, that the type of my datasets will change from data.frame to list.

I recreated the problem in a minimal package using the example package in Rstudio and debugme (1.1.0 from rcran or master from github) on R 3.5.0 and 3.5.1 as follows:

Data creation:
testdata <- data.frame(x=17, y=42)
usethis::use_data(testdata)

.onLoad:
.onLoad <- function(libname, pkgname) {
debugme::debugme()
}

Then after loading the package the (called test) the type of testdata will have changed from a data.frame to a list. If helpful, I can provide the complete test package code that reproduces the error.

I did a little bit of digging and it looks like the error relates to the object set selected for inspection. Specifically, this line in debugme::debugme:
objects <- ls(env, all.names = TRUE)

In my test package, I see this:

objects
".NAMESPACE." ".S3MethodsTable." ".onLoad" ".packageName" "hello"

At the start of the debugme::debugme function I have:

class(test::testdata)
[1] "data.frame"
After calling instrument on namespace (objects[1])
assign(objects[1], debugme:::instrument(get(objects[1], envir=env), pkg), envir=env)
The type changes from data.frame to list
class(test::testdata)
[1] "list"

It looks like the instrumentation of .NAMESPACE. results in a change in the dataset in the package. If I replace the all.names = T to all.names = F in ls:
objects <- ls(env, all.names = F)

Then, my dataset works fine after loading as the ls now excludes patterns starting with dot.

This makes me wonder what the rationale for having all.names = T is? I am wondering if it is to ensure instrumentation of .onLoad and friends or if I am missing something?

[samssann]

#42

[gaborcsardi]

So this is tracked at #42.