22

I'm testing this R package.

The following three things work just fine:

However, the following things

  • devtools::check()
  • devtools::build_win() # (see win-builder output here)

produce this error:

R CMD check results 1 error | 0 warnings | 0 notes checking tests ... ERROR Running ‘testthat.R’ Running the tests in ‘tests/testthat.R’ failed. Last 13 lines of output: 40: mutate_.data.frame(., city_pop = ~readr::parse_number(Population..4), metro_pop = ~readr::parse_number(Population..5), urban_pop = ~readr::parse_number(Population..6), Country = ~gsub(",", "_", Country)) 41: mutate(.data, !(!(!dots))) 42: mutate.data.frame(.data, !(!(!dots))) 43: as.data.frame(mutate(tbl_df(.data), ...)) 44: mutate(tbl_df(.data), ...) 45: mutate.tbl_df(tbl_df(.data), ...) 46: mutate_impl(.data, dots) testthat results ================================================================ OK: 34 SKIPPED: 0 FAILED: 1 1. Error: cities works (@test-etl.R#113) Error: testthat unit tests failed Execution halted

Additionally, the old release Travis-CI job throws an error about dplyr and readr being missing, and the development release Travis-CI job throws an error about not being able to connect to the database. (I sort of suspect that these errors are unrelated to the above.)

I've read this and this and this and this but none of these seem to be my problem.

I've tried all of my usual tricks and I'm fairly confident that there is not actually a bug in the code, there is just some kind of environment/NAMESPACE mismatch that I don't understand and don't know how to debug.

Any ideas? I'm on Ubuntu using R 3.4.1.

MWE

# shell
git clone git@github.com:beanumber/etl.git
# R
library(devtools)
test()
check()
massisenergy
  • 1,764
  • 3
  • 14
  • 25
beanumber
  • 767
  • 5
  • 13
  • I actually solved my own problem (I was using `test_check()` with the wrong package name -- long story!) but would still be happy to see good answers to this question. I've had a number of issues in the past with apparent weirdness in the `check()` and `test()` environments relative to simply `source()`ing the relevant file ... – Ben Bolker Jun 30 '18 at 22:53

1 Answers1

1

I think the best answer (and the one I always use, especially when writing code for others or "self-use" packages) is to use the convention package_name::function() when you use functions imported from other packages.

E.g.:

library(dplyr)
library(plyr)


df <- data.frame(a=rnorm(10), b = c(rep("a",5),rep("b",5)))
df %>% group_by(b) %>% summarise(mean_value = mean(a), count = n())

isn't going to work. dplyr::summarise() will (doing it this way actually throws a very useful warning).

Overall, everytime you load a library you will get a statement saying which functions from the package are already defined elsewhere. E.g. for dplyr on my laptop: The following objects are masked from ‘package:base’: intersect, setdiff, setequal, union

If you look at those warnings you can see which functions you can't / shouldn't call anymore. Note that the in the above case the base function "union" can now only be called by base::union, a standard call of union() will use the dplyr function. In other words, the most recently loaded library is the one used by "default".

Hope that helped

fußballball
  • 329
  • 1
  • 14