R CMD check --as-cran attempts to hide R_LIBS_USER but fails
This has been fixed in R-devel: r78046 | ripley | 2020-03-24 06:51:35 -0700 (Tue, 24 Mar 2020) | 1 line handle Renviron files in the same way as POSIX shells (diff: https://github.com/wch/r-source/commit/1658c8491e9cdc6d2fe61603ed23ae56232b6727) I've verified that 'R CMD check --as-cran' now hides user's personal library (R_LIBS_USER) such that the check environment, including test scripts won't pick up packages from there, e.g. test scripts now report:
print(.libPaths())
[1] "/tmp/hb/Rtmpy6mBCg/RLIBS_1e6465250309" [2] "/home/hb/software/R-devel/trunk/lib/R/library" This is important, because, previously, your package might have not have produced check errors even if all dependencies had not been declared in your DESCRIPTION file, or in your package dependencies. The above is only new for '--as-cran' on Linux and macOS - it already worked as wanted on Windows (see, there's some advantages to be on that OS). /Henrik On Wed, Mar 18, 2020 at 9:38 PM Henrik Bengtsson
<henrik.bengtsson at gmail.com> wrote:
On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel <edd at debian.org> wrote:
On 18 March 2020 at 19:19, Henrik Bengtsson wrote: | AFAIU, 'R CMD check --as-cran' tries to hide any site and user package | libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary What makes you think that? AFAIK --as-cran just sets a bunch of the (nearly countless) environment variables (all described in R Inst+Admin, as I recall) to a set of values "close to" values CRAN uses.
1. --as-cran sets R_LIBS_SITE='no_such_dir' and R_LIBS_USER='',
whereas without --as-cran they're not set.
2. --as-cran sets R_LIBS_USER='no_such_dir' on Windows and there it is
masked, i.e. tests scripts do NOT see user's personal library because
print(Sys.getenv("R_LIBS_USER")) is reported as "'no_such_dir'"
(sic!).
The only other interpretation I can imagine from using R_LIBS_USER=''
on Linux is that is exists there to force the default settings in case
it is already set externally by user. For example, if one do
export R_LIBS_USER="$PWD"
R --vanilla CMD check --as-cran teeny_0.1.0.tar.gz
then tests scripts still get R_LIBS_USER="~/R/x86_64-pc-linux-gnu-library/3.6".
But, then why is there a difference between Windows and Linux in this
essential behavior? To me, this suggests there is a mistake
somewhere. OTH, I know that lots of oddities in R exist for a reason.
/Henrik
| to R_LIBS_SITE, it fails for R_LIBS_USER and the user's personal
| library is still available for test scripts. Should I revise my
| assumptions, or is that intentional?
I would place a nickel on the former if betting was allowed in Illinois.
edd at rob:~$ Rscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
edd at rob:~$ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
edd at rob:~$
I happen to turn per-user libraries off by default, which may affect things.
That said, I actually quite like having the same paths. Your mileage, as they
say, may vary.
Dirk
| The short version. Shouldn't:
|
| $ R_LIBS_USER='' Rscript --vanilla -e ".libPaths()"
| [1] "/home/hb/R/x86_64-pc-linux-gnu-library/4.0"
| [2] "/home/hb/software/R-devel/trunk/lib/R/library"
|
| give the same output as:
|
| $ R_LIBS_USER="no_such_dir" Rscript --vanilla -e ".libPaths()"
| [1] "/home/hb/software/R-devel/trunk/lib/R/library"
|
| ?
|
| The long version:
|
| R_LIBS_SITE='no_such_dir' and R_LIBS_USER='' is set up at the very
| end of tools:::setRlibs():
|
| setRlibs <-
| ...
| c(paste0("R_LIBS=", rlibs),
| if(WINDOWS) " R_ENVIRON_USER='no_such_file'" else "R_ENVIRON_USER=''",
| if(WINDOWS) " R_LIBS_USER='no_such_dir'" else "R_LIBS_USER=''",
| " R_LIBS_SITE='no_such_dir'")
| }
|
| Monitoring with 'pstree' confirms this. On Linux with R 3.6.3, the
| call stack of a 'R CMD check --as-cran teeny_0.1.0.tar.gz' call looks
| like this when a test script is running:
|
| `-sh /usr/lib/R/bin/check --as-cran teeny_0.1.0.tar.gz
| `-R --no-restore --slave --args nextArg--as-crannextArgteeny_0.1.0.tar.gz
| `-sh -c LANGUAGE=en _R_CHECK_INTERNALS2_=1
| R_LIBS=/tmp/hb/RtmpQj4hXb/RLIBS_26e766e32c18 R_ENVIRON_USER=''
| R_LIBS_USER='' R_LIBS_SITE='no_such_dir' '/usr/lib/R/bin/R' --vanilla
| --slave < '/tmp/hb/RtmpQj4hXb/file26e763770b6a'
| `-R --vanilla --slave
| `-sh -c LANGUAGE=C R_TESTS=startup.Rs '/usr/lib/R/bin/R' CMD BATCH
| --vanilla 'env.R' 'env.Rout'
| `-sh /usr/lib/R/bin/BATCH --vanilla env.R env.Rout
| `-R -f env.R --restore --save --no-readline --vanilla
| `-sh -c 'pstree' --arguments --long --show-parents 10558
| `-pstree --arguments --long --show-parents 10558
|
| However, if I call print(Sys.getenv("R_LIBS_USER")) in my tests/env.R,
| I'll find that it is no longer empty but it is indeed set to my
| personal library "~/R/x86_64-pc-linux-gnu-library/3.6".
|
|
| TROUBLESHOOTING:
|
| It looks like R_LIBS_USER is set if and only if it's empty by Renviron
| in my system folder:
|
| $ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
| R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.6'}
| #R_LIBS_USER=${R_LIBS_USER-'~/Library/R/3.6/library'}
| # edd Jul 2007 Now use R_LIBS_SITE, not R_LIBS
| R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
|
| This is from installing R on Ubuntu 18.04 using 'apt install
| r-base-core'. To make sure it's not an issue with that distribution,
| I also check a 'configure/make/make install' from SVN trunk and there
| I see the same:
|
| $ grep R_LIBS < "$(Rscript -e "cat(file.path(R.home('etc'), 'Renviron'))")"
| R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/4.0'}
| #R_LIBS_USER=${R_LIBS_USER-'~/Library/R/4.0/library'}
|
| Printing it during tests/env.R confirms that it is indeed set to
| "~/R/x86_64-pc-linux-gnu-library/4.0".
|
| /Henrik
|
| ______________________________________________
| R-devel at r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org