75

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?

Richie Cotton
  • 118,240
  • 47
  • 247
  • 360
  • 2
    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 ;)). – Marek Jun 07 '10 at 10:23
  • And this thread could be helpful https://stat.ethz.ch/pipermail/r-help/2008-February/153580.html – Marek Jun 07 '10 at 10:25
  • 2
    @Marek: According to the NEWS file, versioned installs were deprecated in R2.9.0. http://cran.r-project.org/src/base/NEWS – Richie Cotton Jun 07 '10 at 13:13
  • 1
    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. – Shane Jun 07 '10 at 13:20

3 Answers3

81

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.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
26

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:

Jozef
  • 2,617
  • 14
  • 19
  • 5
    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... – Dirk Eddelbuettel Dec 30 '18 at 19:34
  • 6
    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. – Jozef Dec 30 '18 at 20:01
  • 3
    @Jozef Since `devtools` is being decomposed into smaller packages, you might want to swap `devtools::install_version()` for `remotes::install_version()`. – Richie Cotton Dec 31 '18 at 21:31
  • 5
    Note that `install_version` will overwrite any existing installation. – jiggunjer Jun 14 '19 at 11:00
-1

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.

Faustin Gashakamba
  • 226
  • 1
  • 12
  • 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`. – Dirk Eddelbuettel Apr 06 '22 at 17:11