Borini, Stefano
2020-Oct-02 07:41 UTC
[R] 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>