Advantages of install.packages() versus BiocManager::install()

Question

[LauferVA]

Suppose we wish to run a workflow requiring a multitude of packages, and that others may use. We could write:

libsNeeded<-c('vsn', 'RColorBrewer', 'pheatmap', 'ggplot2', 'DESeq2', 'dplyr', 'ashr', 'apeglm', 'openxlsx', 'tidyr')
installedLibs <- libsNeeded[(libsNeeded %in% installed.packages()[,"Package"])] # which are installed locally
missingLibs <- libsNeeded[!(libsNeeded %in% installed.packages()[,"Package"])] # which are not 
for (p in libsNeeded) { 
    if (p %in% missingLibs) { install.packages(p) }
    else if (p %in% installedLibs) { update.packages(p) }
}
lapply(libsNeeded, library, character.only = TRUE)

But, what if some of these packages are Bioconductor packages, while others aren't. We could determine which installer to use, e.g., by instead writing:

biocLibs<-BiocManager::available() # obtain list of packages in Bioconductor
cranLibs<-available.packages()[,1] # obtain list of packages in CRAN

Then determining if each of libsNeeded is in one object, the other object, or both. But, in the process of thinking about this, I noticed that:

all(biocLibs %in% cranLibs)
[1] FALSE
all(cranLibs %in% biocLibs)
[1] TRUE

If all CRAN packages are in bioconductor, then I don't necessarily need to write any functionality to select between install.packages() and BiocManager::install(), I could just always use the latter.

But, before doing that, I wanted to ask, is there ever a reason to prefer install.packages()? And slightly more generally, what about the opposite statement? Aside from those packages that aren't in CRAN, is there every a reason to prefer BiocManager if both options are available?

Thanks

[zx8754]

Not the best title, but answers are good:

• Why Bioconductor?

[LauferVA]

NICE find. thank you.

[Nicolas Rosewick]

Not related to bioc or base::install.packages ; but one good way to share workflows and avoid other users to install packages (and associated dependencies) is to share a dockerfile with a R install + list of used packages in your workflow. Thus they can run your workflow within the docker and it should work the same way you executed it (same package version, same R version, etc..). check Rocker :https://rocker-project.org/

Answer 1

[ATpoint]

BiocManager::install() is a wrapper around install.packages() which can do everything the latter can do plus the Bioc-specific parts. You can use it for everything including installing from GitHub without the need for anything else.

I encourage though to make package installation independent from the workflow. Packages may occasionally (or temporarily) be dropped from CRAN or GitHub, or connection issues may occur, killing the whole thing. Installation of dependencies upfront is encouraged, I love containers since they're standardized (e.g. Ubuntu, which the Bioconductor Docker container is based on) plus version-controlled and portable via DockerHub.

[LauferVA]

Perfect. Thanks AT. I can simplify my code a lot as. result. the thread posted by zx8754 is also great.

[Ram]

The worst thing about containers is the upload/download size. Plus, they create a giant temp folder when they run. Great for isolation but I'd rather use regular-use software through conda or HPC modules than use a container. I understand that a well-architected container makes development not-too-different than using plain github repos, but this fad of using containers where a simple version constrained conda environment will do kinda feels like UUoC. I understand that it is great to publish a container - no more "works on my machine" statements and full reproducibility but it's a pain to see every piece of software out there in a container.

[LauferVA]

ATpoint - quick question. when you say,

You can use it for everything including installing from GitHub without the need for anything else.

are you referring to devtools?

[ATpoint]

Yes. Often people use devtools or remotes for install_github but BiocManager can do that as well. So for example BiocManager::install(c('limma', 'atpoint/anypackage')) will work just fine.

[LauferVA]

i see - great. this is the third option i was thinking about, but wanted to keep things simple for the post. thank you.