Story #16264
Updated by Peter Amstutz over 4 years ago
Our build was is currently 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 are running our tests on Debian 9, which ships with R 3.3. A fix was is already committed to upstream Rcpp, so it is likely the problem resolved 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.