Multiple installations

[lgatto]

I first observed this - despite installing/updating aplot, the installation function still wants to update it.

> BiocManager::install("aplot")
'getOption("repos")' replaces Bioconductor standard repositories, see
'help("repositories", package = "BiocManager")' for details.
Replacement repositories:
    CRAN: https://cloud.r-project.org
Bioconductor version 3.17 (BiocManager 1.30.22), R 4.3.1 (2023-06-16)
Installing package(s) 'aplot'
Install system packages...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Reading package lists... Done    
Building dependency tree... Done 
Reading state information... Done
Fetched 0 B in 0s (0 B/s)                                                                                                             

Installation paths not writeable, unable to update packages
  path: /usr/lib/R/library
  packages:
    foreign, lattice, Matrix
  path: /usr/lib/R/site-library
  packages:
    GenomeInfoDbData
Old packages: 'aplot', 'bookdown', 'curl', 'DT', 'GenomeInfoDb', 'harmony',
  'KEGGREST', 'markdown', 'plyr', 'rsconnect', 'vroom'
Update all/some/none? [a/s/n]: n

This might be because aplot is installed in multiple libraries:

> ip <- installed.packages()
> ip[grep("aplot", rownames(ip)), ]
      Package LibPath                                          Version Priority
aplot "aplot" "/home/lgatto/R/x86_64-pc-linux-gnu-library/4.3" "0.2.1" NA      
aplot "aplot" "/usr/lib/R/site-library"                        "0.2.1" NA      
      Depends       
aplot "R (>= 4.1.0)"
aplot "R (>= 4.1.0)"
      Imports                                                                     
aplot "ggfun (>= 0.1.3), ggplot2, ggplotify, patchwork, magrittr,\nmethods, utils"
aplot "ggfun (>= 0.1.3), ggplot2, ggplotify, patchwork, magrittr,\nmethods, utils"
      LinkingTo Suggests Enhances License        License_is_FOSS
aplot NA        "ggtree" NA       "Artistic-2.0" NA             
aplot NA        "ggtree" NA       "Artistic-2.0" NA             
      License_restricts_use OS_type MD5sum NeedsCompilation Built  
aplot NA                    NA      NA     "no"             "4.3.1"
aplot NA                    NA      NA     "no"             "4.3.0"

Is this related to installation in multiple libraries using bioc2u? I've never observed this previously.

[lgatto]

Just to let you know, I get rid of this when removing one of the two installations. Not sure if this is a result of using bioc2u. I think so.

[almahmoud]

I don't have almost any experience with multiple R installations, but @eddelbuettel might have insight/experience with something like this from r2u users

[eddelbuettel]

Yes, thanks, I saw the issue but here I am not sure how BiocManager() may get involved / influence this.

In short, bspm has a few documented options. I often set options(bspm.version.check=FALSE) which to me has a key benefits: by looking only at the binaries (available via apt) it is faster (one less index to read/parse). A downside can be that CRAN (or BioC) may have a new source version for which no binary has been made yet. Having the default value of TRUE allows you to balance both. So try flipping that value and see what happens.

[eddelbuettel]

As for the multiple installations, that is "in some sense not a problem" as you can call .libPaths() a couple of times and add directories as you please (as e.g. renv and other tools do, or as I do here because I like to have roxygen2 version 6.0.1 available to call and not be updated automagically by update.packages().

What can be a problem is that with (per consensus choice with Kurt Hornik and Fritz Leisch decided twenty years ago in a pub in Vienna) that when we have the default of

> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"       "/usr/lib/R/library"           
> 

and r2u / bioc2u now install into /usr/lib/R/site-library then you may still not 'see' the package as a potential older / earlier installation (from source) into /usr/local/lib/R/site-library may 'shadow' it. That is sort-of novel territory -- but both @Enchufa2 and I wrote little helper functions to find 'shadowed packages'. Mine is here.