R-Projekte vor Paket-Updates schützen: renv

pexels.com: Ketut Subiyanto

„Never change a running system!“
„Ändere nie ein System, das funktioniert!“

In aller Regel ist es eine gute Idee, Software aktuell zu halten: also etwa bei R, RStudio und Erweiterungspaketen Updates mitzunehmen. Manchmal haben Updates jedoch die unangenehme Nebenwirkung, bisher funktionierenden Code zu „brechen“.

Beispiel: Interaktives Dashboard funktioniert nicht mehr nach dplyr-Update

Im Video zeige ich ein Beispiel aus eigener Erfahrung: Nach einem dplyr-Update funktionierte ein mit R erstelltes Dashboard nicht mehr, die Interaktivität der Diagramme ging verloren. Meine Lösung bestand darin, renv einzusetzen und damit eine projekt-spezifische Paket-Bibliothek anzulegen. So konnte ich nur für dieses spezielle Projekt auf die bewährte ältere dplyr-Version zugreifen, während meine R-Installation außerhalb des Projekts die neueste dplyr-Version nutzt.

Was ist renv?

renv ersetzt das ältere packrat, ist in RStudio integriert und kann als Projekt-Option unter „Environments“ aktiviert werden.

Mit renv können Projekte eine eigene, projekt-spezifische Paket-Bibliothek erhalten

Voraussetzung, renv zu nutzen, ist demnach, ein RStudio-Projekt anzulegen. Das ist ohnehin eine gute Idee, denn so kann man mit relativen Pfadangaben arbeiten und auf harte Pfade in R-Skripten verzichten (Beispiel: C:/Users/User/Pfad/den/nur/ich/habe). Beim Umstieg auf einen anderen Rechner funktioniert das Projekt sofort, ohne dass Pfadangaben angepasst werden müssten.

Meine erste Erfahrung mit renv war sehr positiv: Auf Anhieb konnte ich leicht beim Umstieg auf einen anderen Rechner die spezielle Projektumgebung mit den gewünschten Paket-Versionen wiederherstellen.

Ausgesprochen wird es übrigens „r-env“, für „R-environments“.

Wie funktioniert renv?

renv legt im Projektordner einen Unterordner „renv“ an, der ein R-Skript und mehrere kleine Dateien mit Systemeinstellungen enthält. Kernstück ist der Unterordner library mit den R-Paketen. Im renv-Ordner liegt zudem das sogenannte lockfile, das für jedes R-Paket die zu verwendende Version beschreibt. Ausschnitt:

Ausschnitt aus einem lockfile von renv, das für jedes im Projekt verwendete Paket die Version aufzeichnet sowie das Verzeichnis, aus dem das Paket installiert wurde. Neben CRAN könnte das z. B. auch github sein.

Überträgt man das Projekt auf einen anderen Rechner, dann muss man nicht den unter Umständen sehr großen Ordner mit den ganzen installierten Paketen mit kopieren. Es genügt, das lockfile zu haben – damit kann renv die Paketversionen am neuen Speicherort des Projekts wiederherstellen.

Ein Unterschied zum sonstigen Arbeiten in R zeigt sich beim Blick auf das Fenster Packages:

Der Reiter Packages enthält unter renv die zusätzlichen Spalten Lockfile und Source.

Hier finden sich nun zwei zusätzliche Spalten: Lockfile und Source. So kann man gefahrlos Paket-Updates ausprobieren. Bewähren sie sich, kann man einen sogenannten Schnappschuss (snapshot) erstellen, der die Paketversionen im Lockfile an den aktuellen Projektstand anpasst. Führt ein Paket-Update jedoch dazu, dass ein R-Skript nicht mehr wie gewünscht funktioniert, kann man zum vorherigen Stand laut letztem Schnappschuss zurückkehren.

Das Schöne daran: Die generelle R-Installation ist davon nicht betroffen. Man kann also gleichzeitig Paket-Updates mitnehmen und ausgewählte Projekte im bewährten Zustand isolieren.

Diese Lösung ist einfacher und schneller umzusetzen, als etwa virtuelle Maschinen wie docker images zu nutzen, die mehr Installationsaufwand erfordern.

Wie sind Eure Erfahrungen mit Paket-Updates und der Stabilität von R-Paketen und R-Skripten?

Freue mich über Kommentare!