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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Henrik Bengtsson-5
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check --as-cran attempts to hide R_LIBS_USER but fails

Dirk Eddelbuettel

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
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check --as-cran attempts to hide R_LIBS_USER but fails

Henrik Bengtsson-5
On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel <[hidden email]> 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'}
> | #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
> |
> | ______________________________________________
> | [hidden email] mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check --as-cran attempts to hide R_LIBS_USER but fails

Henrik Bengtsson-5
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
<[hidden email]> wrote:

>
> On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel <[hidden email]> 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'}
> > | #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
> > |
> > | ______________________________________________
> > | [hidden email] mailing list
> > | https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel