Efficiently Getting Older Versions of R Packages

Efficiently getting older versions of R packages

This is entirely untested (I'm running the latest version of R and have no time at the moment to install an old version of R to test it out), but perhaps one idea is to grab the dates from the "Archive" page for the package, compare that to the date for your R version, and progressively try installing the earlier versions, starting with the most recent version.

Something like this might be a starting point:

install_archive <- function(PackageName) {
if(!require("XML"))
install.packages("XML")
if(!require("devtools"))
install.packages("devtools")
rVersionDate <- as.Date(paste(R.Version()[c("year", "month", "day")],
collapse = "-"))
BaseURL <- "http://cran.r-project.org/src/contrib/Archive/"
u <- htmlParse(paste(BaseURL, PackageName, sep = ""))
doc <- readHTMLTable(u, skip.rows=1:2)[[1]][2:3]
releaseDate <- as.Date(strptime(doc$`Last modified`,
format="%d-%b-%Y"))
Closest <- which.min(rVersionDate -
releaseDate[releaseDate <= rVersionDate])
install_url(paste(BaseURL, doc$Name[Closest], sep = ""))
}

install_archive("reshape")

From here, I would add at least the following things to the function:

  • I would first try to install the most current version (not from the "Archive"), and if that fails, then move ahead.
  • In moving ahead, I would change the which.min() line to rank(), and try rank == 1, rank == 2, and so on, perhaps setting a maximum rank at which to try.

Even so, this is a lot of "guess and check", only the software is doing the guessing and checking for you automatically. And, of course, the same advice holds that there is probably a good reason it's not on CRAN!

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

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.

Pinning R package versions

To provide a little bit more information on packrat, which I use for this purpose. From the website.

R package dependencies can be frustrating. Have you ever had to use
trial-and-error to figure out what R packages you need to install to
make someone else’s code work–and then been left with those packages
globally installed forever, because now you’re not sure whether you
need them? Have you ever updated a package to get code in one of your
projects to work, only to find that the updated package makes code in
another project stop working?

We built packrat to solve these problems. Use packrat to make your R
projects more:

Isolated: Installing a new or updated package for one project won’t
break your other projects, and vice versa. That’s because packrat
gives each project its own private package library. Portable: Easily
transport your projects from one computer to another, even across
different platforms. Packrat makes it easy to install the packages
your project depends on. Reproducible: Packrat records the exact
package versions you depend on, and ensures those exact versions are
the ones that get installed wherever you go.

Packrat stores the version of the packages you use in the packrat.lock file, and then downloads that version from CRAN whenever you packrat::restore(). It is much lighter weight than devtools, but can still take some time to re-download all of the packages (depending on the packages you are using).

If you prefer to store all of the sources in a zip file, you can use packrat::snapshot() to pull down the sources / update the packrat.lock and then packrat::bundle() to "bundle" everything up. The aim for this is to make projects / research reproducible and portable over time by storing the package versions and dependencies used on the original design (along with the source code so that the OS dependency on a binary is avoided).

There is much more information on the website I linked to, and you can see current activity on the git repo. I have encountered a few cases that work in a less-than-ideal way (packages not on CRAN have some issues at times), but the git repo still seems to be pretty active with issues/patches which is encouraging.



Related Topics



Leave a reply



Submit