[R] Unable to compile with R CMD INSTALL on windows when sourcing from Rprofile

[Borini, Stefano]

Hello,

I am currently facing a rather unusual situation. I am running the following command on two windows 10 machines:

C:\\Program Files\\R\\R-3.6.3\\bin\\R.exe CMD INSTALL -l ".envs\\default\\lib" "C:\\Windows\\system32\\config\\systemprofile\\.rip\\cache\\repos\\cloud.r-project.org\\8a5edab282632443219e051e4ade2d1d5bbc671c781051bf1437897cbdfea0f1\\assertthat\\assertthat_0.2.1.tar.gz"

Nothing unusual. I just compile assertthat from targz.

However, I have the following statement in my .Rprofile. (NOTE: .Rprofile, NOT ~/.Rprofile)

print(getwd())
# >>> created by rip
enabled_env <- "default"
source(file.path(".envs", enabled_env, "init.R"))
# <<< created by rip

This init.R file exists and it's correctly sourced, and contains

print('Using environment default')
.libPaths(c('.envs/default/lib'))

The problem occurs on one windows machine, but not the other. On one windows machine I obtain the following, which seems to work (discussion of the differences after the paste):

[1] "C:/<omitted>/Work/my-r-library"
[1] Using environment default
processing 'C:\<omitted>\.rip\cache\repos\cloud.r-project.org\8a5edab282632443219e051e4ade2d1d5bbc671c781051bf1437897cbdfea0f1\assertthat\assertthat_0.2.1.tar.gz'
a file
* build_help_types=html
* DBG: 'R CMD INSTALL' now doing do_install()
* created lock directory 'C:/<omitted>/Work/my-r-library/.envs/default/lib/00LOCK-assertthat'
* installing *source* package 'assertthat' ...
** package 'assertthat' successfully unpacked and MD5 sums checked
** backing up earlier installation
** using staged installation
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
converting help for package 'assertthat'
finding HTML links ... done
<omitted>
** testing if installed package keeps a record of temporary installation path
* DONE (assertthat)

As you can see, nothing unusual. The package is correctly compiled and deployed in the right place. However, on another windows machine, I obtain:

[1] "D:\tomcat-jenkins\workspace\checkout-base-dir\"
[1] "Using environment default"
powershell.exe : * installing *source* package 'assertthat' ...
At D:\tomcat-jenkins\workspace\checkout-base-dir using tmp\durable-37e772e4\powershellWrapper.ps1:3 char:1
+ & powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Comm ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (* installing *s...assertthat' ...    :String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

** package 'assertthat' successfully unpacked and MD5 sums checked
** using staged installation
** R
** byte-compile and prepare package for lazy loading
[1] "C:/Windows/TEMP/RtmpGUTcDs/R.INSTALLeaf825ec54e2/assertthat" ############## <- here [b]
Error in file(filename, "r", encoding = encoding) :
  cannot open the connection
Calls: source -> file
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
  cannot open file '.envs/default/init.R': No such file or directory
Execution halted
ERROR: lazy loading failed for package 'assertthat'
* removing 'D:/tomcat-jenkins/workspace/checkout-base-dir /.envs/default/lib/assertthat'


Discussion:

It seems that R CMD INSTALL spawns, on the second windows, a second R execution instance (seems confirmed in R sources in src/library/tools/R/install.R), however, in the first windows machine, this spawning seems not to happen (or the second R is spawned, but the .Rprofile is never sourced, because as you can see there's no printing of the cwd, see my Rprofile).

All of this is rather absurd, because if the execution fails with being unable to open init.R, it means that it's in the path of the .Rprofile (otherwise the source() statement would never be executed), which also means it should be able to find the path of the init.R because it's in the same directory (relatively speaking)

So the issue seems to happen because the second instance is spawned in the TEMP directory, and the Rprofile is either copied or somehow executed anyway, even if the cwd has changed to the TEMP directory

Do you have any clue of what's going on?

Thanks


--

Stefano Borini
Principal Analytical Tools Developer
AstraZeneca R&D BioPharmaceuticals | Data Science & AI | Early Biometrics & Statistical Innovation




________________________________


AstraZeneca UK Limited is a company incorporated in England and Wales with registered number:03674842 and its registered office at 1 Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only and may contain confidential and privileged information. If they have come to you in error, you must not copy or show them to anyone; instead, please reply to this e-mail, highlighting the error to the sender and then immediately delete the message. For information about how AstraZeneca UK Limited and its affiliates may process information, personal data and monitor communications, please see our privacy notice at www.astrazeneca.com<https://www.astrazeneca.com>