R help - Oct 2020 - Unable to compile with R CMD INSTALL on windows when sourcing from Rprofile

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 at
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>