"Error in !packrat::opts$symlink.system.packages() : invalid argument type"

[nick-youngblut]

I'm not sure if this is a packrat and/or BioManager issue, but please see my comments at rstudio/packrat#524

[nick-youngblut]

Apparently, my comment was not saved in the other issue. The problem is that selecting "a" when prompted Update all/some/none? by biocManager results in the error "Error in !packrat::opts$symlink.system.packages() : invalid argument type". This appears to be caused packrat/biocmanger attempting to do something with the R packages that come in the r-base install for v3.6.2:

$ ls /opt/R/3.6.2/lib/R/library
base   cluster    datasets  grDevices   lattice  methods  nnet      spatial  stats4    tools
boot   codetools  foreign   grid        MASS     mgcv     parallel  splines  survival  translations
class  compiler   graphics  KernSmooth  Matrix   nlme     rpart     stats    tcltk     utils

I don't see why these packages are in the r-base install (eg., nlme), but I simply followed the R install instructions at https://support.rstudio.com/hc/en-us/articles/215488098.

Once "Error in !packrat::opts$symlink.system.packages() : invalid argument type" starts occurring, it keeps occurring for all subsequent package install attempts (biocmanager or install.packages). Why is BiocManager trying to update the packages in my admin-only /opt/R/3.6.2/lib/R/library/ directory?

[mtmorgan]

There's not enough information to reproduce this problem, so we can't really help... minimally, the output of sessionInfo() would help, but it seems like a complicated interaction between BiocManager (which knows nothing about packrat) and packrat (which knows nothing about BiocManager??). Any kind of resolution will require a reproducible example (how can I reproduce the error, without using your system?)

[nick-youngblut]

Sorry for the lack of info. I did have it all in the other issue, but that comment wasn't saved for some reason. I don't know what's changed but now I get:

The downloaded packages are in 
	‘/tmp/Rtmp4A9yKX/downloaded_packages’
Updating HTML index of packages in '.Library'
Warning messages:
1: In file.create(f.tg) :
  cannot create file '/opt/R/3.6.2/lib/R/doc/html/packages.html', reason 'Permission denied'
2: In make.packages.html(.Library) : cannot update HTML package index

when selecting all for package update during BiocManager::install(version = "3.10").

The number of packages that BiocManager wants to update is now only a few (boot, foreign, and MASS) instead of ~20 packages as it previously was. This is with a completely new project.

A "reproducible" example is:

• A new project in Rstudio Server Pro 1.2.5019-6 Professional (Elderflower), using R 3.6.2
• init packrat
• run BiocManger install as shown at https://www.bioconductor.org/install/
  • select "a" when prompted to update (what was originally most of the packages in /opt/R/3.6.2/lib/R/library, but is now just boot, foreign, and MASS

The BiocManger install should then fail with many "Error in !packrat::opts$symlink.system.packages() : invalid argument type" errors.

sessioninfo:

R version 3.6.2 (2019-12-12)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.3 LTS

Matrix products: default
BLAS:   /opt/R/3.6.2/lib/R/lib/libRblas.so
LAPACK: /opt/R/3.6.2/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] BiocManager_1.30.10 compiler_3.6.2      tools_3.6.2        
[4] packrat_0.5.0 

[mtmorgan]

I don't have access to the professional version of RStudio. If I start a new packrat project (via File -> New Project -> New Directory -> New Project and click the appropriate flag) in /private/tmp/packrat-test I have

> .libPaths()
[1] "/private/tmp/packrat-test/packrat/lib/x86_64-apple-darwin17.7.0/3.6.1"    
[2] "/private/tmp/packrat-test/packrat/lib-ext/x86_64-apple-darwin17.7.0/3.6.1"
[3] "/private/tmp/packrat-test/packrat/lib-R/x86_64-apple-darwin17.7.0/3.6.1"  

which is good -- all the paths where R will install packages are under my user account. I see

> lapply(.libPaths(), dir)
[[1]]
[1] "packrat"

[[2]]
character(0)

[[3]]
 [1] "base"       "boot"       "class"      "cluster"    "codetools" 
 [6] "compiler"   "datasets"   "foreign"    "graphics"   "grDevices" 
[11] "grid"       "KernSmooth" "lattice"    "MASS"       "Matrix"    
[16] "methods"    "mgcv"       "nlme"       "nnet"       "parallel"  
[21] "rpart"      "spatial"    "splines"    "stats"      "stats4"    
[26] "survival"   "tcltk"      "tools"      "utils"     

so the base and recommended (boot, foreign, ... are so-called 'recommended' packages, base, stats, ... are 'base' packages) are in the third directory. These are symbolic links to the system-wide packages

> system2("ls", c("-al", file.path(.libPaths()[3], "boot")))
lrwxr-xr-x  1 ma38727  wheel  44 Jan  5 08:01 /private/tmp/packrat-test/packrat/lib-R/x86_64-apple-darwin17.7.0/3.6.1/boot -> /Users/ma38727/bin/R-3-6-branch/library/boot

My installation has the recommended packages in a writeable location owned by me, but I guess your installation has the recommended packages in a location owned by another account.

I install BiocManager, e.g., using the RStudio interface or from R, and it gets installed into the first .libPaths(), as expected.

> install.packages("BiocManager")
...
> dir(.libPaths()[1])
[1] "BiocManager" "packrat"    

The next step installs another package, BiocVersion, used to track the version of Bioconductor in use; it's installed where I expect it.

> BiocManager::install(version="3.10")
...
> dir(.libPaths()[1])
[1] "BiocManager" "BiocVersion" "packrat" 

If I try to 'update' (my versions are not out-of-date, but I think this has the same effect as answering a to the prompt...) one of the recommended packages I have

> BiocManager::install("boot")
...
> dir(.libPaths()[1])
[1] "BiocManager" "BiocVersion" "boot"        "packrat"   

and again the package gets installed in the first .libPaths(). The system installation appears untouched

> system2("ls", c("-al", file.path(.libPaths()[3], "boot")))
lrwxr-xr-x  1 ma38727  wheel  44 Jan  5 08:01 /private/tmp/packrat-test/packrat/lib-R/x86_64-apple-darwin17.7.0/3.6.1/boot -> /Users/ma38727/bin/R-3-6-branch/library/boot

It could be that there are differences in package installation versus package update, so my recommendation is to answer n to the prompt to update boot, etc., and then to separately update these explicitly, using BiocManager or the RStudio graphical user interface, e.g.,

BiocManager::install(c("boot", "foreign", "MASS"))

I think this would be a 'one-time' workaround, subsequent prompts to update boot would just work when replying a. You could 'update' all recommended packages

> pkgs = installed.packages()[,"Priority"]
> recommended = names(base::subset(pkgs, pkgs == "recommended"))
> BiocManager::install(recommended)

or perhaps there is a packrat option to copy rather than symlink recommended / system packages. Another good option would be to avoid installing the recommended packages as sudo by adding --without-recommended-packages to the configure step of the instructions you link to; the recommended packages can be installed as needed using standard (e.g., BiocManager::install()) commands.

[mtmorgan]

any progress @nick-youngblut ? without a reproducible example it's not clear that this is a BiocManager issue and if not I'd like to close the issue.

[nick-youngblut]

Sorry, but your 'one-time' workaround idea didn't work. I'm still getting the symlink errors. I think that there is a packrat option to have it copy instead of symlink. Regardless, I've switched to renv, which doesn't seem to have this problem. Maybe that's the best solution.

[mtmorgan]

Ok I'll close the issue because I haven't been able to reproduce it and because it may not be a BiocManager problem per se. If there is additional information you'd like to add, including re-opening the issue, please feel free to do so.

Many issues like this are better handled on the Bioconductor support site https://support.bioconductor.org.