Handle R SDK dependencies better
Our build was broken for a while because Rcpp (a transitive dependency of a package we depend on) had a new release that is broken on R 3.3.
We were running our tests on Debian 9, which ships with R 3.3.
A fix was committed to upstream Rcpp, so the problem resolved itself, but we should have a more stable strategy for R dependencies.
Recompiling R dependencies every time is also very expensive.
Use Debian packages¶
When we did the R SDK originally (about two years ago) most of the packages we needed were not in Debian. Since then, it appears they have been added to Debian 10, and are also available in a Debian 9 backport:
Of course this requires targeting Debian for the test builds, but we do that already. To get the maximum benefit it also requires that all the R packages we need are in Debian.
R doesn't have anything like a Gemfile.lock or "pip freeze". However someone has created a tool that computes an install plan so each package is installed at exactly each version we want.
This works on any R install. The drawback is that we still end up compiling the whole world every time.