How do you use multiple versions of the same R package?

Question

In order to be able to compare two versions of a package, I need to able to choose which version of the package that I load. R's package system is set to by default to overwrite existing packages, so that you always have the latest version. How do I override this behaviour?

My thoughts so far are:

I could get the package sources, edit the descriptions to give different names and build, in effect, two different packages. I'd rather be able to work directly with the binaries though, as it is much less hassle.

I don't necessarily need to have both versions of the packages loaded at the same time (just installed somewhere at the same time). I could perhaps mess about with Sys.getenv('R_HOME') to change the place where R installs the packages, and then .libpaths() to change the place where R looks for them. This seems hacky though, so does anyone have any better ideas?

Epode

In help to update.packages is mentioned argument installWithVers. You could try to check it (or I'll check later and post as an answer ;)). – Manizales

And this thread could be helpful stat.ethz.ch/pipermail/r-help/2008-February/153580.html – Manizales

@Marek: According to the NEWS file, versioned installs were deprecated in R2.9.0. cran.r-project.org/src/base/NEWS – Epode

You could also use two different R versions (e.g. R 2.11 and 2.11.1), and have the different packages split across them; then you can run both versions at once. I frequently do this myself. – Dinghy

Answer 1

You could selectively alter the library path. For complete transparency, keep both out of your usual path and then do

 library(foo, lib.loc="~/dev/foo/v1")    ## loads v1

and

 library(foo, lib.loc="~/dev/foo/v2")    ## loads v2

The same works for install.packages(), of course. All these commands have a number of arguments, so the hooks you aim for may already be present. So don't look at changing R_HOME, rather look at help(install.packages) (assuming you install from source).

But AFAIK you cannot load the same package twice under the same name.

Waxwork

And for installing you can if necessary do lb = .libPaths(); .libPaths(c('/custom/path', lb)) – Wolk

Answer 2

Many years have passed since the accepted answer which is of course still valid. It might however be worthwhile to mention a few new options that arised in the meanwhile:

Managing multiple versions of packages

For managing multiple versions of packages on a project (directory) level, the packrat tool can be useful: https://rstudio.github.io/packrat/. In short

Packrat enhances your project directory by storing your package dependencies inside it, rather than relying on your personal R library that is shared across all of your other R sessions.

This basically means that each of your projects can have its own "private library", isolated from the user and system libraries. If you are using RStudio, packrat is very neatly integrated and easy to use.

Installing custom package versions

In terms of installing a custom version of a package, there are many ways, perhaps the most convenient may be using the devtools package, example:

devtools::install_version("ggplot2", version = "0.9.1")

Alternatively, as suggested by Richie, there is now a more lightweight package called remotes that is a result of the decomposition of devtools into smaller packages, with very similar usage:

remotes::install_version("ggplot2", version = "0.9.1")

More info on the topic can be found:

• https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages

Tired

With all due respect for the effort in brushing up an eight (!!) year old question, OP did not ask about managing dependencies and did not about installation of pinned version numbers so you are shouting into the void here... – Waxwork

The way I understood the question is OP is trying to use multiple versions of one package. For this one needs to do 2 things: 1) install multiple versions of the package (for which I suggested devtools::install_version) 2) safely manage where will they be installed and loaded from (for which I mentioned packrat) - which effectively does something very similar to your original answer, just in a (subjectively) easier way. – Tired

@Tired Since devtools is being decomposed into smaller packages, you might want to swap devtools::install_version() for remotes::install_version(). – Epode

Note that install_version will overwrite any existing installation. – Senecal

Answer 3

I worked with R for a longtime now and it's only today that I thought about this. The idea came from the fact that I started dabbling with Python and the first step I had to make was to manage what they (pythonistas) call "Virtual environments". They even have dedicated tools for this seemingly important task. I informed myself more about this aspect and why they take it so seriously. I finally realized that this is a neat and important way to manage different projects with conflicting dependencies. I wanted to know why R doesn't have this feature and found that actually the concept of "environments" exists in R but not introduced to newbies like in Python. So you need to check the documentation about this and it will solve your issue. Sorry for rambling but I thought it would help.

Antilepton

You are overlooking that R has had that feature for some time: packrat (as in @Jozef's answer) and its newer follow-up (same author) renv. – Waxwork