Idea #16264
Updated by Peter Amstutz about 4 years ago
Our build is currently broken because Rcpp (a transitive dependency of a package we depend on) had a new release that is broken on R 3.3.
We are running our tests on Debian 9, which ships with R 3.3.
A fix is already committed to upstream Rcpp, so it is likely the problem will resolve itself, but we should have a more stable strategy for R dependencies.
Recompiling R dependencies every time is also very expensive.
h2. Options
h3. 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:
https://packages.debian.org/search?keywords=r-cran-devtools&searchon=names&suite=all§ion=all
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.
h3. Pinned install
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.
https://www.ccdatalab.org/blog/2019/8/9/pinning-transitive-r-dependencies-for-fun-and-reproducible-builds
This works on any R install. The drawback is that we still end up compiling the whole world every time.