Okay, the title may be a little misleading. But it addresses the problem I have.

I’m running many different R projects in production. So they must run in a reproductive way and I can’t afford that the programs break if a package update is installed.

Official Way To Solve This Problem

There are some package manager for R available. But all of them have some drawbacks

  • Packrat
    • Setting snapshots and going back and forth doesn’t work for me and I was getting a mess.
    • Packrat doesn’t work well when you are using locally hosted packages.
    • It gets really complicated when you use packages from CRAN which you’ve patched locally.
  • MRAN
    • Uses only snapshots of CRAN. So you can’t use local packages.
  • miniCRAN
    • Uses local copy of CRAN packages.
    • I had problems with multi-platform setup: Developing on a Mac and going productive on a Linux server.

My Solution

I’ve found a way around these package managers. I began using git a safety net. So my directory ~/Library/R/3.6/library containing all my locally installed R-packages is a git repository.

When I (accidently) install an update of a package I can go back using all the power of git.

So now I can use a branch for each project. When I need to update a package for project A all other projects aren’t affected.

But do I tell project A to use the correct branch of my repository?

I checkout each branch with the command git worktree add ~/RLIBS/<project> <BRANCH>

In the project-directory I add an .Renviron-file with this content

1

R_LIBS=~/RLIBS/<project>

Caveat

If you’re using RStudio for package development you may have to set the right library-directory in your user’s home-driectory .Renviron file because when you build the new package RStudio runs a new R-session with your home-directory as working directory.

So always check your lib-paths with .libPaths().

The downside of this behaviour is that it isn’t simple to put an update of a project with new libraries into production. I think therefor docker is an interesting alternative.

Note

This article is the result of a lightning-talk I held at Campus useR Group Frankfurt.