[Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails

Henrik Bengtsson henr|k@bengt@@on @end|ng |rom gm@||@com
Tue Mar 24 19:11:09 CET 2020


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 using gmail.com> wrote:
>
> On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel <edd using 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 using rob:~$ Rscript --vanilla -e ".libPaths()"
> >   [1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
> >   [3] "/usr/lib/R/library"
> >   edd using 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 using 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 using r-project.org mailing list
> > | https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org



More information about the R-devel mailing list