@nuest As I mentioned here Internal CRAN-like system - best practices inability of packrat (or checkpoint) to deal with system dependencies is the main reason we use Nix package manager.
A recent example: a user requested sf - a package for spatial data which depends on a standard library from GDAL project. It turned out that our version of Linux did not have packages for new-ish versions of GDAL. So the choice was between building GDAL from sources (and then maintaining the install to keep it compatible with future upgrades of both R and R packages) and just running one Nix command:
nix-shell -p R rPackages.sf --run R
which takes care of bulding and caching correct versions of all c++ libraries and corresponding R packages. That command is guaranteed to keep working for all future upgrades of all the moving parts. If I need to throw in some python packages to the environment (tensorflow?), it would be a matter of adding them to the command line and Nix will make sure that all versions of everything will be compatible with each other. Another bonus - if I so desire, the "sandbox" will be invisible to anybody else (including my other projects which may require different versions of the tools). The command line can be replaced by a short script in the Nix language which I can then run to enter the sandbox.
Regarding Docker vs. Nix, I really like this post https://blog.wearewizards.io/why-docker-is-not-the-answer-to-reproducible-research-and-why-nix-may-be.
The reproducibility issue is solved automaticall by the fact that the "recipes" for all Nix packages consititute a single entity - the Nix Packages collection and it is trivial to pin a particular commit of Nixpkgs in either that command line or the corresponding nix script.