CredibilityLab / groundhog

Reproducible R Scripts Via Date Controlled Installing & Loading of CRAN & Git Packages
https://groundhogr.com/
GNU General Public License v3.0
78 stars 4 forks source link

Outdated binaries in MRAN #36

Closed urisohn closed 4 years ago

urisohn commented 4 years ago

There is a problem when installing binaries from MRAN. When visiting MRAN and asking for a binary MRAN may deliver an earlier version if for the requested date they only had the current vesion as source.

Here is an example, groundhog.library() was trying to install stringi_1.4.5 but it installed 1.4.4, and put it in the 1.4.5 folder image

you can reproduce it: groundhog.library("stringi","2020-02-11") There are a few solutions to this. 1) One could crawl MRAN an create a mran.toc.rds with the binary for each package for each date. 2) One could, before installing from MRAN verifying it has the right version

I wrote this function to that effect:

get.mran.version=function(pkg,date){
  url=paste0("https://mran.microsoft.com/snapshot/",date)
  ap=data.frame(available.packages(repos=url,type='binary'))
  row=subset(ap,Package==pkg)
  version=as.character(row$Version)
  return(version)
  }

get.mran.version("stringi","2020-02-11") My inclination is to go with (2), and if the wrong version is obtained, then a another MRAN date is tried, and if that fails, it goes to source.

But before implementing this i wanted to get your reaction.

I would put it into the function that computes the binary date for the MRAN download

Bisaloo commented 4 years ago

Yes, 2 sounds good