Using different/modified version of the same package

[This article was first published on R on B. Ogan Mancarci, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Sometimes a package on CRAN doesn’t behave quite as you would like. Maybe a change introduced broke your workflow so you want an older version, maybe you want to add additional functionality and the maintainer is uninterested in incorporating your changes which may not fit the scope or they are simply inactive and inaccessible. Now you have a version of the package that you need that conflicts with CRAN.

To make my life easier in a case like this I have written a small function forkCRAN (code below). So I can simply do

# read my github token for authentication
token = readLines('~/auth/gh_token')
forkCRAN('ontologyIndex', version = '2.5', token=token, newname = 'ontologyIndexOgfork')

and have a this github repository that contains ontologyIndex, version 2.5 with the name ontologyIndexOgfork. I can use this repository like any other github package


In this particular case, the original ontologyIndex package could not parse cyclic ontologies. I have introduced some changes so that it can parse such ontologies and my current pipeline depends on this change. Having this version allows me to write unambigious code that still can be replicated by third parties, especially since including remote package dependencies is fairly easy when using remotes/devtools family of install functions.

You can find forkCRAN function here. Can be safely pasted elsewhere since it doesn’t depend on anything else in the package it’s in.

Note that this isn’t entirely safe to do. Especially when all you want to do is to use an older version. The code of the package will be preserved but it’s dependencies will continue to move forward in time. There are more robust solutions out there for long term reproducibility.

Another problem is that this doesn’t always behave nicely with pacakges that require compilation. In these cases the package name seems to be hard coded into the code. I initially noticed this when I tried to get a copy of the glue package. For that particular case, all it took to fix it was to change the useDynLib commands in the NAMESPACE and roxygen comments to use the new package. This change now happens automatically when the function is called but I have failed to make a generalized solution. dplyr package for instance will still fail to work.

To leave a comment for the author, please follow the link and comment on their blog: R on B. Ogan Mancarci. offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

Never miss an update!
Subscribe to R-bloggers to receive
e-mails with the latest R posts.
(You will not see this message again.)

Click here to close (This popup will not appear again)