Using different/modified version of the same package

July 30, 2019
By

[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

devtools::install_github('oganm/ontologyIndexOgfork')
library(ontologyIndexOgfork)

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.

R-bloggers.com 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.



If you got this far, why not subscribe for updates from the site? Choose your flavor: e-mail, twitter, RSS, or facebook...

Comments are closed.

Search R-bloggers

Sponsors

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)