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