Recently I asked about this very topic on Twitter, which sparked the creation of a neat shiny app by Andy Teucher which checks the R dependency of each package imported/suggested by a certain package.
@hadley noted uncertainty regarding this approach, so I would like to discuss this further.
My initial question was more concerned with the “direct” dependency on a specific version of base R, which I am entirely unsure how to determine, since my primary package makes use of various functions from
methods, but I wouldn’t know where to start when someone were to ask me which minimal R version I rely on. Checking each imported package’s R dependency seems reasonable, but it doesn’t actually factor in where the actual dependency on R comes in to play.
I am aware of travis ci, which I already use to verify my package is working on
devel, but when it comes to checking older versions, travis falls short because packages I depend on can’t be installed due to a higher R version dependency.
The question is then: Ignoring package dependencies, what is the bare minimum R version my package actually relies on, and therefore:
If every package was required to declare an absolute minimum R version instead of just declaring the most recent version for convenience, wouldn’t that improve the R package ecosystem because it would allow many older, possibly strictly managed R installations (maybe on “conservative” OSes like debian or CentOS) to make use of more packages?
devtools-like tools to assess your usage of base R functions with regards to version requirements? Does the
backports package need to be considered? Is this question even useful in the grand scheme of things? All I wanted to do was to fill in the
Depends field in my package
DESCRIPTION responsibly, and all I got was this headache.
Please share your thoughts or experience.