libpath for RD --vanilla lacks /usr/lib/R/library about rocker

[eddelbuettel]

It was an (old) recommendation / suggestion by R Core members that lead to the current scheme which I have used in the Debian package for over a decade.

I'd be rather reluctant to change that.

[wch]

You don't need to change the Debian package for R -- just the libpath that's used for RD. Specifically, this line:

rocker/debian/r-devel/Dockerfile

Line 87 in f8288d0

RUN echo "R_LIBS_SITE=\${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib/R/library'}" > /usr/local/lib/R/etc/Renviron.site

[wch]

Here's a reproducible example of the problem. This is a package check with --vanilla. I picked a package that you might have some interest in. :)

$ docker run --rm -ti rocker/r-devel /bin/bash

# wget http://cran.r-project.org/src/contrib/digest_0.6.4.tar.gz
# RD --vanilla CMD check digest_0.6.4.tar.gz
* using log directory ‘//digest.Rcheck’
* using R Under development (unstable) (2014-10-27 r66886)
* using platform: x86_64-unknown-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘digest/DESCRIPTION’ ... OK
* this is package ‘digest’ version ‘0.6.4’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘digest’ can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... NOTE
Error in loadNamespace(name) : there is no package called ‘codetools’
Calls: <Anonymous> ... tryCatch -> tryCatchList -> tryCatchOne -> <Anonymous>
Execution halted
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... WARNING
Error in find.package(package, lib.loc) : 
  there is no package called ‘MASS’
Calls: <Anonymous> -> lapply -> FUN -> find.package
Execution halted
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... OK
* checking examples ... OK
* checking for unstated dependencies in tests ... OK
* checking tests ...
  Running ‘AESTest.R’
  Comparing ‘AESTest.Rout’ to ‘AESTest.Rout.save’ ... OK
  Running ‘digestTest.R’
  Comparing ‘digestTest.Rout’ to ‘digestTest.Rout.save’ ... OK
  Running ‘hmacTest.R’
  Comparing ‘hmacTest.Rout’ to ‘hmacTest.Rout.save’ ... OK
 OK
* checking PDF version of manual ... OK
* DONE

WARNING: There was 1 warning.
NOTE: There was 1 note.
See
  ‘//digest.Rcheck/00check.log’
for details.

It has some trouble finding the "standard" packages codetools and MASS for the check. These packages are present in /usr/lib/R/library, but not /usr/local/lib/R/library. The changes I proposed above apparently will fix this issue (although I think I had problems checking some other packages even with that change, so there may be some other hidden problems).

[eddelbuettel]

Thanks for the example. This may convince me :)

There is in fact some recent-ish R CMD change that makes this worse. I run into this the few times I test on Windoze when it frequently fails to find my default packages. I think the intent is to have a more minimal package basis against which to test. But it is a pain as it claims no Rcpp found etc pp.

I'll apply your fix as it is local to Docker.

[wch]

I think now that setting R_LIBS_SITE is correct, instead of R_LIBS. According to the docs:

The library search path is initialized at startup from the environment variable R_LIBS (which should be a colon-separated list of directories at which R library trees are rooted) followed by those in environment variable R_LIBS_USER. Only directories which exist at the time will be included.

This means that if the user has set R_LIBS_USER, it will come after everything specified in R_LIBS.

In the setup I'm using, here's ~/.Renviron:

# cat ~/.Renviron 
R_LIBS_USER=~/R-lib/%v

And here's the resulting libpath:

# RDscript -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/local/lib/R/library"     
[3] "/usr/lib/R/library"            "/root/R-lib/3.2"     

The problem is that packages don't get installed to R_LIBS_USER, which I have mounted on a Docker volume so that they persist across container runs.

If R_LIBS_SITE is set instead of R_LIBS, then you get this, which is better:

# RDscript -e ".libPaths()"
[1] "/root/R-lib/3.2"               "/usr/local/lib/R/site-library"
[3] "/usr/local/lib/R/library"      "/usr/lib/R/library"   

[eddelbuettel]

Dude ....

[eddelbuettel]

I am of the strongly held opinion that R packages below ~ or ${HOME} are the devil and must be avoided. If you have a sorting problem, please fix it locally with an env var prior to calling R CMD check.

I like having at the end of the .libPath() so you are facing a steep uphill battle trying to convince me to change that... ;-)

[cboettig]

looks like we can close this now (?)