R-Pakete: install.packages(), library() und CRAN

Was ein Paket ist

Ein Paket ist ein Bündel aus Funktionen, Dokumentation und manchmal Daten, das R erweitert. Base R gibt dir Vektoren, Modelle und Diagramme; Pakete geben dir alles andere - und dieses "alles andere" ist gewaltig. CRAN (das Comprehensive R Archive Network) beherbergt rund 20.000 Pakete, jedes davon vor der Veröffentlichung gegen CRANs Einreichungstests geprüft. Dieses Repository ist der Hauptgrund, warum R für Datenarbeit konkurrenzfähig bleibt: Was auch immer die Analyse ist, jemand hat sie wahrscheinlich schon paketiert.

CRAN ist nicht die einzige Quelle - Bioconductor beherbergt das Bioinformatik-Ökosystem, und viele Pakete in Entwicklung leben auf GitHub (installierbar mit remotes::install_github()) -, aber als Einsteiger kannst du CRAN als Standard behandeln und die anderen als das, was dir begegnet, wenn eine README es dir sagt.

Eine Handvoll Pakete kommt mit R selbst (stats, utils, graphics und Co.) und lädt automatisch - deshalb funktionieren mean() und plot() einfach so. Alles andere folgt dem zweistufigen Ritual unten.

install.packages() einmal, library() in jeder Sitzung

Das ist die Verwirrung Nummer 1 bei Anfängern, also hier so knapp wie möglich. Ein Paket zum Laufen zu bringen sind zwei verschiedene Handlungen mit zwei verschiedenen Lebensdauern:

install.packages("dplyr")   # ONCE per machine: downloads from CRAN and installs
library(dplyr)              # EVERY session: loads it so your code can use it

• install.packages("dplyr") ist wie ein Buch kaufen: Du tust es einmal, und es steht von da an in deinem Regal (auf deiner Festplatte). Beachte die Anführungszeichen - du übergibst den Namen als Zeichenkette.
• library(dplyr) ist wie das Buch aus dem Regal nehmen: Du tust es zu Beginn jeder R-Sitzung (praktisch: am Anfang jedes Skripts). Hier sind keine Anführungszeichen nötig - library() ist speziell und akzeptiert den nackten Namen (library("dplyr") funktioniert ebenfalls, wenn du Konsistenz bevorzugst).

Die zwei Fehlermodi verraten dir, welchen Schritt du ausgelassen hast. Error: there is no package called 'dplyr' von library() bedeutet, es wurde nie installiert. Error: could not find function "filter" (oder "%>%") mitten im Skript bedeutet, das Paket ist installiert, aber diese Sitzung hat es nie geladen. Jeden library()-Aufruf ganz an den Anfang des Skripts zu setzen - nicht über das Skript verstreut - macht den zweiten Fehler in der ersten Sekunde sichtbar und dient zugleich als Liste der Abhängigkeiten des Skripts. tidyverse zu installieren funktioniert genauso: install.packages("tidyverse") einmal, library(tidyverse) pro Sitzung, was dplyr, ggplot2 und den Rest des Kernsets in einer Zeile lädt.

Was du nicht tun solltest, ist install.packages() in einem Skript stehen zu lassen, das du wiederholt ausführst oder teilst - es lädt bei jedem Lauf neu herunter und kann den überraschen, der es ausführt. Installieren ist eine Konsolenhandlung; Laden ist eine Skripthandlung.

require() und pkg::fun()

require() sieht wie ein Synonym für library() aus, und es als solches zu missbrauchen ist verbreitet. Der Unterschied ist, was bei fehlendem Paket passiert: library() stoppt mit einem Fehler; require() gibt eine Warnung aus, liefert FALSE zurück und lässt das Skript weiterlaufen - meist um zwanzig Zeilen später mit einem verwirrenden "could not find function" statt der ehrlichen "no package called"-Meldung zu sterben. Zum Laden von Abhängigkeiten nutze library(): laut und oben zu scheitern ist ein Feature. require() verdient sein Geld nur in bedingten Prüfungen, wo sein Rückgabewert der Punkt ist:

if (!require(praise)) {
    install.packages("praise")
    library(praise)
}

Es gibt außerdem einen Weg, ein Paket zu nutzen, ohne es überhaupt zu laden: Der ::-Operator ruft eine Funktion über ihre vollständige Adresse auf, package::function(). Das Paket muss installiert sein, aber nichts wird an deine Sitzung angehängt:

print(stats::sd(c(2, 4, 6, 8)))   # full address: package stats, function sd

print(exists("some_dplyr_thing")) # nothing extra was attached to the session

(stats wird ohnehin automatisch geladen, also funktioniert auch schlichtes sd() - aber die Syntax ist für jedes installierte Paket dieselbe.) :: glänzt an zwei Stellen: bei einmaligen Aufrufen, für die eine ganze library()-Zeile überzogen wäre, und zur Disambiguierung, wenn zwei geladene Pakete denselben Namen exportieren - dplyr::filter() vs. stats::filter() ist die klassische Kollision.

Pakete aktuell halten

Pakete entwickeln sich unabhängig von R, das Aktualisieren liegt also bei dir:

update.packages()          # offers to update everything outdated
update.packages(ask = FALSE)   # same, without prompting per package

Eine nicht offensichtliche Regel: Pakete werden gegen eine bestimmte major.minor-Version von R gebaut. Wenn du R selbst aktualisierst (etwa 4.3 auf 4.4 - siehe R installieren), wird deine alte Paketbibliothek in der Regel nicht übernommen, und die Lösung besteht schlicht darin, die genutzten Pakete unter der neuen Version neu zu installieren. Zehn Minuten install.packages(), keine Katastrophe - aber es überrascht Leute beim ersten Mal, wenn ihre Skripte eine frische R-Installation mit einer Wand aus "no package called"-Fehlern begrüßen.

Sehen, was du hast

Drei Funktionen beantworten "Was ist installiert und wo?":

installed.packages()[, "Version"]   # every installed package with its version
sessionInfo()                       # R version + what THIS session has loaded
.libPaths()                         # the folders where packages are installed

installed.packages() gibt eine Matrix mit einer Zeile pro Paket zurück - die Spalte Version ist meist das, was du willst. sessionInfo() ist das Reproduzierbarkeitswerkzeug: Füg seine Ausgabe in einen Fehlerbericht ein, und der Leser kennt deine R-Version, dein Betriebssystem und die exakten Versionen jedes geladenen Pakets. .libPaths() zeigt die Bibliotheksordner, die R durchsucht; zu wissen, dass es das gibt, entzaubert "Wo ist dieses Paket eigentlich gelandet?" und warum auf gemeinsam genutzten Rechnern manchmal Administratorrechte eine Rolle spielen.

Pakete, die man kennen sollte

Du brauchst diese heute nicht, aber du wirst ihnen ständig begegnen - zu wissen, wofür jedes da ist, hilft dir, den Code anderer zu lesen:

• dplyr - die Datenmanipulationsverben: filter, mutate, group_by, summarize.
• ggplot2 - das Standard-Grafikpaket; die meisten R-Grafiken, die du online siehst, sind ggplot2.
• tidyr - Umformen von Daten zwischen breiter und langer Form (pivot_longer, pivot_wider).
• readr / readxl - schnelles Einlesen von CSV bzw. das Lesen von Excel-Dateien.
• lubridate - Datumswerte, die sich so verhalten, wie du es erwartest.
• stringr - konsistente Zeichenkettenbearbeitung.
• data.table - ein alternatives Hochleistungs-Data-Frame-Ökosystem; ein anderer Dialekt als das Tidyverse, geschätzt für große Daten.
• shiny - interaktive Web-Apps, komplett in R geschrieben.

Die ersten sechs sind der Kern des Tidyverse und kommen zusammen mit install.packages("tidyverse"). Es besteht keine Pflicht, eines davon zu nutzen - Base R kann all das auch -, aber im Ökosystem lebt der Großteil des modernen R-Codes.

Was du mitnimmst

• CRAN beherbergt ~20.000 geprüfte Pakete; Bioconductor und GitHub decken den Rest ab.
• install.packages("name") einmal pro Rechner (Anführungszeichen erforderlich); library(name) einmal pro Sitzung, am Anfang des Skripts.
• library() scheitert laut - gut; require() gibt FALSE zurück - nur in Prüfungen nützlich.
• pkg::fun() nutzt eine Funktion, ohne das Paket anzuhängen, und löst Namenskollisionen auf.
• update.packages() hält alles aktuell; ein größeres R-Upgrade bedeutet, Pakete neu zu installieren.
• sessionInfo() ist der Weg, jemandem (oder deinem zukünftigen Ich) genau zu sagen, worauf dein Code lief.

Als Nächstes: das Arbeitsverzeichnis - wo R nach Dateien sucht und warum das das Erste ist, was du prüfst, wenn das Einlesen von Daten scheitert.