Pacchetti R: install.packages(), library() e CRAN

Cos'è un pacchetto

Un pacchetto è un insieme di funzioni, documentazione e a volte dati che estende R. R base ti dà vettori, modelli e grafici; i pacchetti ti danno tutto il resto, e "tutto il resto" è enorme. CRAN (il Comprehensive R Archive Network) ospita circa 20,000 pacchetti, ognuno verificato con i test di invio di CRAN prima della pubblicazione. Questo archivio è il motivo principale per cui R resta competitivo nel lavoro sui dati: qualunque sia l'analisi, probabilmente qualcuno l'ha già messa in un pacchetto.

CRAN non è l'unica fonte: Bioconductor ospita l'ecosistema della bioinformatica, e molti pacchetti in sviluppo vivono su GitHub (installabili con remotes::install_github()), ma all'inizio puoi considerare CRAN come la fonte predefinita e le altre come cose che incontrerai quando un README ti dirà di usarle.

Un piccolo gruppo di pacchetti arriva insieme a R (stats, utils, graphics e compagnia) e si carica automaticamente: è per questo che mean() e plot() funzionano e basta. Tutto il resto segue il rituale in due passaggi descritto qui sotto.

install.packages() una volta, library() a ogni sessione

È la confusione numero uno di chi inizia, quindi eccola nel modo più netto possibile. Far funzionare un pacchetto richiede due azioni diverse con due durate diverse:

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") è come comprare un libro: lo fai una volta, e da quel momento resta sul tuo scaffale (il tuo disco). Nota le virgolette: stai passando il nome come stringa.
• library(dplyr) è come prendere il libro dallo scaffale: lo fai all'inizio di ogni sessione R (in pratica, all'inizio di ogni script). Qui le virgolette non servono: library() è speciale e accetta il nome senza virgolette (funziona anche library("dplyr"), se preferisci la coerenza).

I due tipi di errore ti dicono quale passaggio hai saltato. Error: there is no package called 'dplyr' da library() significa che il pacchetto non è mai stato installato. Error: could not find function "filter" (o "%>%") a metà di uno script significa che il pacchetto è installato ma questa sessione non l'ha mai caricato. Mettere tutte le chiamate a library() proprio all'inizio dello script, e non sparse qua e là, rende visibile il secondo errore nel primo secondo, e fa anche da elenco delle dipendenze dello script. Installare tidyverse funziona allo stesso modo: install.packages("tidyverse") una volta, library(tidyverse) a ogni sessione, e in una riga carica dplyr, ggplot2 e il resto del nucleo principale.

Quello che non dovresti fare è lasciare install.packages() dentro uno script che esegui spesso o che condividi: riscarica tutto a ogni esecuzione e può sorprendere chi lo avvia. Installare è un'azione da console; caricare è un'azione da script.

require() e pkg::fun()

require() sembra un sinonimo di library(), ed è comune usarlo come tale. La differenza è cosa succede quando il pacchetto manca: library() si ferma con un errore; require() stampa un avviso, restituisce FALSE e lascia proseguire lo script, che di solito muore venti righe dopo con un confuso "could not find function" invece dell'onesto messaggio "no package called". Per caricare le dipendenze, usa library(): fallire in modo evidente all'inizio è un pregio. require() si guadagna il posto solo nei controlli condizionali, dove il valore che restituisce è proprio ciò che serve:

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

C'è anche un modo per usare un pacchetto senza caricarlo affatto: l'operatore :: chiama una funzione con il suo indirizzo completo, package::function(). Il pacchetto deve essere installato, ma alla sessione non viene collegato niente:

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 viene comunque caricato in automatico, quindi funziona anche il semplice sd(), ma la sintassi è la stessa per qualsiasi pacchetto installato.) :: dà il meglio in due situazioni: chiamate singole in cui un'intera riga library() sarebbe eccessiva, e per togliere ambiguità quando due pacchetti caricati esportano lo stesso nome: dplyr::filter() contro stats::filter() è la collisione classica.

Tenere aggiornati i pacchetti

I pacchetti evolvono indipendentemente da R, quindi aggiornarli tocca a te:

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

Una regola non ovvia: i pacchetti sono compilati per una specifica versione major.minor di R. Quando aggiorni R stesso (per esempio da 4.3 a 4.4, vedi installare R), la tua vecchia libreria di pacchetti di solito non viene trasferita, e la soluzione è semplicemente reinstallare i pacchetti che usi con la nuova versione. Dieci minuti di install.packages(), non un disastro, ma sorprende la prima volta che i tuoi script accolgono una nuova installazione di R con un muro di errori "no package called".

Vedere cosa hai installato

Tre funzioni rispondono a "cosa è installato e dove":

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() restituisce una matrice con una riga per pacchetto, e di solito ti interessa la colonna Version. sessionInfo() è lo strumento per la riproducibilità: incolla il suo output in una segnalazione di bug e chi legge conosce la tua versione di R, il sistema operativo e le versioni esatte di ogni pacchetto caricato. .libPaths() mostra le cartelle di libreria in cui R cerca; sapere che esiste chiarisce il mistero di "dove è finito davvero quel pacchetto?" e perché a volte sui computer condivisi servono i permessi di amministratore.

Pacchetti che vale la pena conoscere

Oggi non ti servono, ma li incontrerai di continuo, e sapere a cosa serve ciascuno ti aiuta a leggere il codice degli altri:

• dplyr: i verbi per manipolare i dati: filter, mutate, group_by, summarize.
• ggplot2: il pacchetto standard per i grafici; la maggior parte dei grafici R che vedi online è fatta con ggplot2.
• tidyr: trasformare i dati tra formato largo e lungo (pivot_longer, pivot_wider).
• readr / readxl: rispettivamente lettura veloce dei CSV e lettura dei file Excel.
• lubridate: date che si comportano come ti aspetti.
• stringr: manipolazione delle stringhe coerente.
• data.table: un ecosistema alternativo di data frame ad alte prestazioni; un dialetto diverso dal tidyverse, amatissimo per i big data.
• shiny: app web interattive scritte interamente in R.

I primi sei sono il nucleo del tidyverse e arrivano tutti insieme con install.packages("tidyverse"). Non c'è alcun obbligo di usarli, perché R base può fare tutto, ma è nell'ecosistema che vive la maggior parte del codice R moderno.

Cosa ti porti a casa

• CRAN ospita circa 20,000 pacchetti verificati; Bioconductor e GitHub coprono il resto.
• install.packages("name") una volta per computer (virgolette obbligatorie); library(name) una volta per sessione, all'inizio dello script.
• library() fallisce in modo evidente, ed è un bene; require() restituisce FALSE, utile solo dentro i controlli.
• pkg::fun() usa una funzione senza collegare il pacchetto, e risolve le collisioni di nomi.
• update.packages() tiene tutto aggiornato; un aggiornamento importante di R significa reinstallare i pacchetti.
• sessionInfo() è il modo per dire a qualcuno (o al te del futuro) esattamente su cosa è stato eseguito il tuo codice.

Prossimo passo: la directory di lavoro, dove R cerca i file e perché è la prima cosa da controllare quando la lettura dei dati fallisce.