What is best practice when a dependency is removed from CRAN?

Tags: #<Tag:0x00007f5a00997cd8>

Hi all, what’s the best practice for dealing with package dependencies that are no longer available on CRAN, but for which archived versions are still compatible?

For instance, we use RecordLinkage for Jaro-Winkler similarity. The package was removed from CRAN a few weeks ago, but archive versions are available.

  1. Is it possible to install dependencies from the archive site as a short-term solution? What about including the archived version of the package with our own?

  2. Along those lines, what about absorbing the relevant code from the now-deprecated package? I think the analyses we require use 1-2 functions from their package. I’m unclear of what the rules/ethics are here, beyond attribution.

  3. Finally, we can probably edit our code to use another package that calculates J-W (there is one other one - stringdist). But it seems like 2, if an acceptable practice, might work both well and quickly.

Thanks for the help. I’m a total novice when it comes to writing and maintaining packages…a dropped dependency shortly after finishing is a heck of an introduction to the process!

I think #2 is the best way to go here. This is the beauty of open source :slight_smile:. The thing one has to check in this case is whether RecordLinkage’s license allows this. In this case, it’s GPL (>= 2), which means code in it can be used by other GPL software. You use GPL-3, so you’re all set! It’s always useful to add in comments to your files/docs as to the origin of the functions. You can also add the authors of RecordLinkage as contributors (ctb) in your DESCRIPTION.

1 Like

Those are good suggestions. I’ll also note that often packages are archived on CRAN for really minor policy violations, and it can be exhausting as a maintainer to deal with the churn. And so sometimes it takes us a month or two to get a package back out of the archive and republished. So, its probably worth checking with the package maintainer to see if it being in the archive is just a temporary thing while they jump through CRAN hoops. And, in the spirit of open source, maybe a #4 option would be:

#4: Help contribute patches that fix the problems that caused the package to be archived and get it back into CRAN

I think that is a community-minded approach to maintenance, and might be preferred over forking the code, which creates two places that code would need to be maintained.


Thanks for the feedback. It appears the package failed some checks for the latest version of R, and was removed because of its ORPHANED maintainer status. All the dependencies listed in the error message (below) are still on CRAN, so it could be an easy fix. There’s a protocol for someone to fix and take over as maintainer, but maybe option 4 is the best option.

ERROR: dependencies ‘DBI’, ‘RSQLite’, ‘ff’, ‘ffbase’, ‘e1071’, ‘ada’, ‘ipred’, ‘evd’, ‘data.table’ are not available for package ‘RecordLinkage’

  • removing ‘C:/Users/User/Documents/R/win-library/3.6/RecordLinkage’
    Warning in install.packages :
    installation of package ‘C:/Users/User/Downloads/RecordLinkage_0.4-11.tar.gz’ had non-zero exit status

Hi all, an update - I wrote the developers and got no response. While waiting I was able to edit our code to use the stringdist package instead without too much trouble. Thanks for the helpful advice.

1 Like