thr3ads.net - R devel - [Rd] R CMD check --as-cran attempts to hide R_LIBS

If this information is useful, please help other people find it:
Share via:

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

head link

[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

head link

[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

Maybe Matching Threads

Search for more maybe matching threads

R devel - Mar 2020 - R CMD check --as-cran attempts to hide R_LIBS_USER but fails

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

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

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

Maybe Matching Threads