Skip to content
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

R can't find packages installed by travis #4641

Closed
zachmayer opened this issue Aug 10, 2015 · 6 comments
Closed

R can't find packages installed by travis #4641

zachmayer opened this issue Aug 10, 2015 · 6 comments
Labels

Comments

@zachmayer
Copy link

@craigcitro and @hadley
We're trying to add some unit tests to the caret package that get run by travis, but not on CRAN. This saves build time on CRAN and reduces the number of dependencies they have to install to check our package, while letting us run a more complete test suite on travis.

I thought I could simply install the requirements for the test using the r_packages: line in my travis.yml file:

    r_packages:
     - ROSE
     - DMwR

However, my NOT_CRAN=TRUE builds are still failing. (NOT_CRAN=FALSE runs fine as the problematic tests are skipped)

This is really strange, as when I look at the build logs, I see travis successfully installing all the packages I need:

    * installing *source* package ‘ROSE’ ...
    ** package ‘ROSE’ successfully unpacked and MD5 sums checked
    ** R
    ** data
    ** inst
    ** preparing package for lazy loading
    ** help
    *** installing help indices
    ** building package indices
    ** testing if installed package can be loaded
    * DONE (ROSE)

But when my tests run that depend on those packages, R can't find them:

    > library(testthat)
    > library(caret)
    Loading required package: lattice
    Loading required package: ggplot2
    > 
    > test_check("caret")
    [1] "Reduced dimension to 3 by default. "
    1 package is needed for this model and is not installed. (ROSE). Would you like to try to install it now?1. Error: check appropriate sampling calls by name -----------------------------

    1: withCallingHandlers(eval(code, new_test_environment), error = capture_calls, message = function(c) invokeRestart("muffleMessage"), 
           warning = function(c) invokeRestart("muffleWarning"))
    2: eval(code, new_test_environment)
    3: eval(expr, envir, enclos)
    4: caret:::parse_sampling(i) at test_sampling_options.R:14
    5: checkInstall(pkgs)
    6: stop()

    testthat results ================================================================
    OK: 62 SKIPPED: 0 FAILED: 1
    1. Error: check appropriate sampling calls by name 

    Error: testthat unit tests failed
    Execution halted

(I think) the relevant line of code is here in caret's source code:

    good <- rep(TRUE, length(pkg))
      for(i in seq(along = pkg)){
        tested <- try(find.package(pkg[i]), silent = TRUE)
        if(class(tested)[1] == "try-error") good[i] <- FALSE
      }

Why can't the find.package function find packages installed by travis? Do they go in a special, separate library somewhere?

Also, as an aside, how do I make my travis builds for r less verbose? By default they seem to print way too much information (e.g. it echoes all code run by the tests and manual, even code that doesn't error).

@zachmayer
Copy link
Author

@zachmayer
Copy link
Author

P.S.: I tried to add the community:r label, but couldn't.

@craigcitro
Copy link

the install scripts for travis aren't doing anything special -- they use devtools, but they ultimately call into install.packages to do the actual package installation.

does caret play any games with library paths or installing its own packages?

@zachmayer
Copy link
Author

Nope. But it seems "R CMD CHECK --as-cran" does play games with the library paths, setting library to /usr/lib/R/library. (See here on stackoverflow)

@hadley
Copy link

hadley commented Aug 11, 2015

During R CMD check, only packages explicitly listed in the DESCRIPTION are made available, so unfortunately your basic approach won't work.

@stale
Copy link

stale bot commented Apr 14, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants