Another common question when we discuss RStudio Package Manager is how to manage multiple users installing different versions of the same packages. Consider, for example, the case where you’ve developed a Shiny application that requires ggplot 2.2.1, but for a new project your colleague wants to use the tidyverse which requires ggplot 3.0.
To understand the answer, it is important to understand the difference between a repository and a library. A repository contains uninstalled (though sometimes compiled) R packages. A repository can hold one or more versions of a package.
A library contains an installed package, tied to a specific version of R. A library can only contain one version of each package.
install.packages is responsible for taking a package from a repository and installing it into a library. The
library command, in turn, loads a package into the R session.
To handle multiple versions of packages across projects, then, you have to create an environment where different projects use different libraries. To determine which library to use, R uses the function
.libPaths, but using this function manually can be a pain. Most languages have tools for managing “libraries” (virtualenv, npm, etc) and R has a number of options including a tool called packrat.
A much more detailed discussion is necessary to handle the details of these tools including packrat. However, in many of my discussions I’ve had, it turns out that RStudio Connect meets the needs of the organization to isolate projects. RStudio Connect uses packrat and automatically handles package dependencies and isolating project libraries. If you need to deploy-and-forget shiny apps, R Markdown documents, or plumber APIs, start by looking into RStudio Connect. It may meet your needs even without RStudio Package Manager.
We’ve also worked hard to ensure RStudio Package Manager supports packrat as well as enabling other options for handling change control.