Henrik Bengtsson
2020-Mar-19 02:19 UTC
[Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails
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 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? 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
Dirk Eddelbuettel
2020-Mar-19 03:04 UTC
[Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails
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. | 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
Henrik Bengtsson
2020-Mar-19 04:38 UTC
[Rd] R CMD check --as-cran attempts to hide R_LIBS_USER but fails
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
Apparently Analagous Threads
- R CMD check --as-cran attempts to hide R_LIBS_USER but fails
- R CMD check --as-cran attempts to hide R_LIBS_USER but fails
- How to go about getting a change in the SPEC file from which R is built on EPEL?
- Improving RPM packaging for R; ideas gathered from the Debian folks
- R CMD check error