-
Notifications
You must be signed in to change notification settings - Fork 968
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
testthat does not recognize data.tables ? #2053
Comments
It seems to be connected to building the package:
allows the function run correctly, except in unittests (I'm guessing testthat uses load_all()) PS. So far the minimal example is virtually the only thing I have actually implemented in the package. There is no other code that could be interfering or altering behaviour etc. |
@jangorecki It seems to be the same issue, discovered via different route. I don't know if it is because of something data.tables has changed or because of something that devtools has changed. At least it seems it is not something testthat did. So I guess the next step is to go knock on devtools' door to see if they know anything about what's going on here. |
I see that you've added it in your roxygen comments. |
I had a similar issue. Googling, I found this https://stackoverflow.com/questions/13106018/data-table-error-when-used-through-knitr-gwidgetswww/13131555#13131555
to the top of the file causing the problem, and it now works. I don't understand why though |
I am having the same problem, but the workaround posted above does not reliably work for me. This is mildly frustrating. Data.table is in general absolutely fantastic! Any updates on this issue? |
would adding |
To no avail, any other suggestions? I really appreciate your time. Please let me know if I can help to provide more information. |
throwing random ideas for trying: |
@asantucci Be sure to read FAQ about this. You need to have proper import in DESCRIPTION and NAMESPACE files. Do not rely on helpers like roxygen when verifying if your imports are properly defined. Always check if problem still occurs when building and checking from console. |
If problems cannot be reproduced from R console I think this issue can be closed, unless someone has some action points related to this issue. I found the following issues related: devtools#192 and devtools#1472. |
Thanks, @jangorecki for the related links. For what it's worth, the first, devtools#192, simply dead-ends without a solution (in fact pointing back to this thread). The second, devtools#1472, was almost helpful, in that it encouraged me to re-install/update the For using Continually surprised that given the popularity of data.table and testthat, that this is still an ongoing issue. Posting here not because I'm complaining (both packages are individually amazing), but because I'd like for future programmers to find this more easily. |
Hi @asantucci, would adding #’ @import data.table in at lease one of the functions that depend on data.table help? |
Sufficient, yes. But not necessary.
Not my experience. It's possible you edited the NAMESPACE file once, after which I suspect that there's something askew in your package: the roxygen roclets, the NAMESPACE file, or the build process itself. My first test would be to remove |
@chinsoon12 please read new doc on that: https://rdatatable.gitlab.io/data.table/library/data.table/doc/datatable-importing.html |
I went ahead and did the following
@jangorecki Perhaps consider mentioning that this Still to be improved (call me greedy); a future developer may stumble upon the lone Thanks everyone, for your time. |
@asantucci IMO proper way is to write NAMESPACE by hand :) I am pretty sure roxygen documentation mention what you are asking about. I used roxygen in many packages but only for Rd files, not NAMESPACE file which I like to format well myself. Troubleshooting section in our vignette is quite clear:
|
@jangorecki That's great you like to spend time formatting the NAMESPACE by hand. I'd venture a guess that you're a small minority in that regard. I respectfully disagree that I'm "asking about roxygen documentation"; I'm using both |
@asantucci Everyone is frustrated. Not sure if you found this one or not (I can't see it linked above) : That contains the link to the FAQ, too, where the same info is repeated. Searching the FAQ for "import" would have found it, at the point Jan mentioned there was a FAQ about it. (Maybe he was writing from a phone which is why he didn't give you a link directly to it.) The fact is that Roxygen/Rstudio attempts to write and overwrite your NAMESPACE file for you, to make your life easier. But sometimes fails, as in this case it seems, and makes your life harder. Please talk to them about that and let us know how you get on. If an imported package does not actually appear in NAMESPACE, then it isn't going to work. So while this apparent bug in Roxygen/Rstudio persists, you need to carefully check your NAMESPACE file to see if that line is there or not. Another annoyance is that R needs the imported package to be named in both places: DESCRIPTION and NAMESPACE. And if it is in only one of those, there is no helpful warning or note as far as I remember. It could be that recent versions of R now warn/note and it could be that RStudio does not show that to you. It all takes time to investigate, search r-devel history and liaise with people. Since it effects you most, could you do that please? An update to R, or an update to roxygen/RStudio in this regard would be appreciated by a great many folk. As far as I know it affects a lot of packages and is nothing to do with data.table per se. |
@mattdowle and @jangorecki Thanks for this. Just to summarize: See for reference: https://stackoverflow.com/a/10529888/403310 https://stackoverflow.com/a/36930626/1317443 https://rdatatable.gitlab.io/data.table/library/data.table/doc/datatable-importing.html I was able to solve these issues with roxygen2 v6.1 data.table 1.11.4 and R 3.5.1 by
|
Thank you all for this. I had the same issue. After much frustration, as @ChandlerLutz and others stated above, simply adding (I made an empty function just for this purpose and explicitly documented it, so that it will not likely be later removed by accident. NB: I also have R 3.5.2, data.table 1.12.0, roxygen2 6.1.0.9000 |
hi I am having this issue as well, but my package suggests data.table (not imports). I reported the issue to testthat r-lib/testthat#933 but @hadley wrote "This is almost certainly because of the way that data.table checks for whether or not it's in a data.table aware environment, and is unlikely to be directly related to testthat" to reproduce the issue I created a MRE package here, https://github.com/tdhock/testdtbug In particular the [.data.frame method seems to be incorrectly called when using [ on a data.table during test_package (but not test_file), which results in an "object not found" error. I expected that tests should pass using both test_package and test_file, but tests only pass using test_file. the code to reproduce the error is: remotes::install_github("tdhock/testdtbug", force=TRUE, INSTALL_opts="--install-tests")
testthat::test_package("testdtbug")
testthat::test_file(system.file("tests", "testthat", "test-dt.R", package="testdtbug"))
devtools::session_info() The output on my system was: > remotes::install_github("tdhock/testdtbug", force=TRUE, INSTALL_opts="--install-tests")
Downloading GitHub repo tdhock/testdtbug@master
v checking for file 'C:\Users\th798\AppData\Local\Temp\RtmpK2I3xH\remotes33186a156572\tdhock-testdtbug-e7a14c5/DESCRIPTION'
- preparing 'testdtbug':
v checking DESCRIPTION meta-information
- checking for LF line-endings in source and make files and shell scripts
- checking for empty or unneeded directories
- creating default NAMESPACE file
- building 'testdtbug_2019.9.3.tar.gz'
Installing package into 'C:/Users/th798/R/win-library/3.6'
(as 'lib' is unspecified)
* installing *source* package 'testdtbug' ...
** using staged installation
** tests
** help
No man pages found in package 'testdtbug'
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (testdtbug)
> testthat::test_package("testdtbug")
-- 1. Error: dt [ method ok (@test-dt.R#5) ------------------------------------
object 'foo' not found
1: data.table(group = 1:2, foo = "bar")[, {
expect_identical(foo, "bar")
}, by = group] at C:/Users/th798/R/win-library/3.6/testdtbug/tests/testthat/test-dt.R:5
2: `[.data.table`(data.table(group = 1:2, foo = "bar"), , {
expect_identical(foo, "bar")
}, by = group) at C:/Users/th798/R/win-library/3.6/testdtbug/tests/testthat/test-dt.R:5
3: `[.data.frame`(x, i, j)
4: expect_identical(foo, "bar") at C:/Users/th798/R/win-library/3.6/testdtbug/tests/testthat/test-dt.R:6
5: quasi_label(enquo(object), label, arg = "object")
6: eval_bare(get_expr(quo), get_env(quo))
== testthat results ===========================================================
[ OK: 0 | SKIPPED: 0 | WARNINGS: 0 | FAILED: 1 ]
1. Error: dt [ method ok (@test-dt.R#5)
Error: testthat unit tests failed
> testthat::test_file(system.file("tests", "testthat", "test-dt.R", package="testdtbug"))
v | OK F W S | Context
v | 2 | dt
== Results =====================================================================
OK: 2
Failed: 0
Warnings: 0
Skipped: 0
> devtools::session_info()
- Session info ---------------------------------------------------------------
setting value
version R version 3.6.1 (2019-07-05)
os Windows 10 x64
system x86_64, mingw32
ui RTerm
language (EN)
collate English_United States.1252
ctype English_United States.1252
tz America/Phoenix
date 2019-09-04
- Packages -------------------------------------------------------------------
! package * version date lib source
assertthat 0.2.1 2019-03-21 [1] CRAN (R 3.6.1)
backports 1.1.4 2019-04-10 [1] CRAN (R 3.6.1)
callr 3.3.1 2019-07-18 [1] CRAN (R 3.6.1)
cli 1.1.0 2019-03-19 [1] CRAN (R 3.6.1)
crayon 1.3.4 2017-09-16 [1] CRAN (R 3.6.1)
curl 3.3 2019-01-10 [1] CRAN (R 3.6.1)
data.table * 1.12.2 2019-04-07 [1] standard (@1.12.2)
desc 1.2.0 2018-05-01 [1] CRAN (R 3.6.1)
devtools 2.1.0 2019-07-06 [1] CRAN (R 3.6.1)
digest 0.6.20 2019-07-04 [1] CRAN (R 3.6.1)
fs 1.3.1 2019-05-06 [1] CRAN (R 3.6.1)
glue 1.3.1 2019-03-12 [1] CRAN (R 3.6.1)
htmltools 0.3.6 2017-04-28 [1] CRAN (R 3.6.1)
htmlwidgets 1.3 2018-09-30 [1] CRAN (R 3.6.1)
magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.1)
memoise 1.1.0 2017-04-21 [1] CRAN (R 3.6.1)
namedCapture * 2019.8.13 2019-08-14 [1] local
pkgbuild 1.0.3 2019-03-20 [1] CRAN (R 3.6.1)
pkgload 1.0.2 2018-10-29 [1] CRAN (R 3.6.1)
prettyunits 1.0.2 2015-07-13 [1] CRAN (R 3.6.1)
processx 3.4.1 2019-07-18 [1] CRAN (R 3.6.1)
ps 1.3.0 2018-12-21 [1] CRAN (R 3.6.1)
R6 2.4.0 2019-02-14 [1] CRAN (R 3.6.1)
Rcpp 1.0.2 2019-07-25 [1] CRAN (R 3.6.1)
D RcppParallel 4.4.3 2019-05-22 [1] CRAN (R 3.6.1)
re2r 0.2.0 2017-09-04 [1] CRAN (R 3.6.1)
remotes 2.1.0 2019-06-24 [1] standard (@2.1.0)
rlang 0.4.0 2019-06-25 [1] CRAN (R 3.6.1)
rprojroot 1.3-2 2018-01-03 [1] CRAN (R 3.6.1)
sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 3.6.1)
stringi 1.4.3 2019-03-12 [1] CRAN (R 3.6.0)
testdtbug 2019.9.3 2019-09-04 [1] Github (tdhock/testdtbug@e7a14c5)
testthat * 2.2.0 2019-07-22 [1] CRAN (R 3.6.1)
usethis 1.5.1 2019-07-04 [1] CRAN (R 3.6.1)
withr 2.1.2 2018-03-15 [1] CRAN (R 3.6.1)
[1] C:/Users/th798/R/win-library/3.6
[2] c:/Program Files/R/R-3.6.1/library
D -- DLL MD5 mismatch, broken installation.
> This also happens when running R --vanilla:
This is happening both on MacOs (see r-lib/testthat#933) and on windows (as shown above) |
@tdhock thanks for reporting. Are you able to reproduce the issue when putting NAMESPACE file in your package? I think that NAMESPACE is mandatory for a package to be valid, since 2.14 or 3.0.0. |
.datatable.aware=TRUE seems to fix the problem, thanks for the suggestion. May I suggest a change to the importing vignette? It is clear that .datatable.aware is needed if data.table is imported, but it is not clear that it is necessary when it is suggested. (as in my case where I only want to use data.table in vignettes and tests) It would be great if you could mention that in the section "Optionally import data.table: Suggests" for example When using a package as a suggested dependency, you should not import it in the NAMESPACE file. Just mention it in the DESCRIPTION file. When using data.table functions in package code (R/* files) you need to use the data.table:: prefix because none of them are imported. When using data.table in package tests (e.g. tests/testthat/test* files), you need to declare .datatable.aware=TRUE in one of the R/* files. |
@tdhock sure, moreover you are welcome to submit PR directly. |
ok here is the pr master...tdhock:patch-1 |
i mean here, #3818 |
I started developing a new package using newer dat.table version and got stopped fairly early on but what seems to be an issue between 'testthat' and 'data.table'. I did not encounter that issue working with both packages for my previous package.
I have a function like this in my package:
And this is the corresponding unittest:
I get this error:
But if I call the function from a prompt or run it line for line it runs fine.
The text was updated successfully, but these errors were encountered: