-
Notifications
You must be signed in to change notification settings - Fork 752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
devtools::test when package Depends on data.table, but does not import it #192
Comments
Wild guess is that devtools needs to create .Depends in the namespace environment, to mimick more closely what R itself does. When I looked at devtools NEWS for 0.8, it appeared that devtools simulates a namespace, or creates one itself somehow. So it isn't a namespace exactly as would be created by R CMD INSTALL followed by library() ? |
It's not exactly the same, but it's getting closer each version. Since we use imports and not depends, the depends code hasn't been tested as well, but bug reports like this help us prioritise features for new versions. |
Great, thanks. I'll close the data.table bug report then, now it's confirmed as likely a devtools issue. |
Thanks to a suggestion from Matthew Dowle, a workaround for me is to add .datatable.aware=TRUE in my package, which makes this problem disappear. |
Yeah, this was probably related to the fact we weren't loading any packages in depends. |
Closed in fa70de6 |
@hadley Is this bug related to http://stackoverflow.com/q/24501245/513006 and http://stackoverflow.com/q/23252231/513006? If so, should it be reopened? Here is a reproducible example from the first link library(devtools)
setwd(tempdir())
# make dummy package called foo
create("foo")
setwd("foo")
# add data.table as a package dependency
a <- readLines("DESCRIPTION")
depends.idx <- grepl("Depends", a)
a[depends.idx] <- paste0(a[depends.idx], ", data.table")
writeLines(a, "DESCRIPTION")
# create a dummy function
writeLines("myfunction <- function() {a <- data.table(b=1); return(a[,b])}",
"R/foo.R")
# check and throw error
check() # fails but documents and compiles
library(foo)
myfunction() |
I can't replicate this issue with R 3.2.0, data.table 1.9.4 and devtools 1.8.0. Need to create a
|
I seem to be encountering the same issue as discussed above. I posted a related question on stackoverflow: http://stackoverflow.com/questions/36547235/r-data-table-and-testthat-package |
Also getting identical error:
Tried all the tips included here, read all relevant Stack Overflow posts, and updated my |
This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/ |
When a package Depends on data.table (and does not import it), sometimes using devtools::test on the package can break some functions that use data.table. I filed a bug report for data.table, but it's not clear that is a data.table issue. Here is the link to the data.table bug report: https://r-forge.r-project.org/tracker/?func=detail&atid=975&aid=2367&group_id=240
I don't see a way to attach files to this, but here is a link (that should be a direct download) to the package that I attached to the data.table bug report: https://r-forge.r-project.org/tracker/download.php/240/975/2367/275/anRpackage_1.0.tar.gz
The package has 2 functions: myFun assigns some values to a column of a data.table by reference. myFun2() creates a data.table, and then calls myFun() to change the values of one of the columns of the data.table myFun2() created.
The package also has a testthat test that simply tests that myFun2 returns a data.table.
The package passes R CMD check, and test_dir. However, if I use devtools::test, I get an error, and for the remainder of the R session, myFun() and myFun2() will fail with the same error.
Here is a link to the output from an interactive session (attached to the data.table bug report) showing the problem: https://r-forge.r-project.org/tracker/download.php/240/975/2367/276/interactive.txt
The text was updated successfully, but these errors were encountered: