Les packages R : install.packages(), library() et le CRAN

Ce qu'est un package

Un package est un ensemble de fonctions, de documentation et parfois de données qui étend R. R de base te donne les vecteurs, les modèles et les graphiques ; les packages te donnent tout le reste - et ce « tout le reste » est immense. Le CRAN (Comprehensive R Archive Network) héberge environ 20 000 packages, chacun passé au crible des tests de soumission du CRAN avant publication. Ce dépôt est la principale raison pour laquelle R reste compétitif pour le travail de données : quelle que soit l'analyse, quelqu'un l'a probablement empaquetée.

Le CRAN n'est pas la seule source - Bioconductor héberge l'écosystème de bio-informatique, et de nombreux packages en développement vivent sur GitHub (installables avec remotes::install_github()) - mais en tant que débutant tu peux traiter le CRAN comme la source par défaut et les autres comme des choses que tu croiseras quand un README te le dira.

Une poignée de packages sont livrés avec R lui-même (stats, utils, graphics et compagnie) et se chargent automatiquement - c'est pourquoi mean() et plot() fonctionnent d'emblée. Tout le reste suit le rituel en deux temps ci-dessous.

install.packages() une fois, library() à chaque session

C'est la confusion n°1 des débutants, alors la voici le plus nettement possible. Faire fonctionner un package, ce sont deux actions différentes avec deux durées de vie différentes :

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"), c'est comme acheter un livre : tu le fais une fois, et il reste sur ton étagère (ton disque) ensuite. Note les guillemets - tu passes le nom sous forme de chaîne.
• library(dplyr), c'est comme prendre le livre sur l'étagère : tu le fais au début de chaque session R (en pratique, en tête de chaque script). Pas de guillemets nécessaires ici - library() est spéciale et accepte le nom nu (library("dplyr") marche aussi, si tu préfères la cohérence).

Les deux modes d'échec te disent quelle étape tu as sautée. Error: there is no package called 'dplyr' venant de library() signifie qu'il n'a jamais été installé. Error: could not find function "filter" (ou "%>%") au milieu d'un script signifie que le package est installé mais que cette session ne l'a jamais chargé. Mettre tous les appels library() tout en haut du script - et non éparpillés - rend le second échec visible dès la première seconde, et sert en prime de liste des dépendances du script. Installer tidyverse fonctionne pareil : install.packages("tidyverse") une fois, library(tidyverse) par session, ce qui charge dplyr, ggplot2 et le reste du noyau en une ligne.

Ce que tu ne devrais pas faire, c'est laisser install.packages() dans un script que tu lances régulièrement ou que tu partages - il retélécharge à chaque exécution et peut surprendre celui qui l'exécute. L'installation est un acte de console ; le chargement est un acte de script.

require() et pkg::fun()

require() ressemble à un synonyme de library(), et l'utiliser comme tel est fréquent. La différence, c'est ce qui se passe quand le package manque : library() s'arrête sur une erreur ; require() affiche un avertissement, renvoie FALSE et laisse le script continuer - généralement pour mourir vingt lignes plus loin avec un « could not find function » déroutant plutôt que l'honnête message « no package called ». Pour charger des dépendances, utilise library() : échouer fort en haut est une fonctionnalité. require() ne gagne sa place que dans des tests conditionnels, où sa valeur de retour est justement le sujet :

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

Il existe aussi un moyen d'utiliser un package sans le charger du tout : l'opérateur :: appelle une fonction par son adresse complète, package::fonction(). Le package doit être installé, mais rien n'est attaché à ta session :

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 est chargé automatiquement de toute façon, donc sd() tout simple marche aussi - mais la syntaxe est la même pour n'importe quel package installé.) :: brille dans deux cas : les appels ponctuels où une ligne library() complète serait excessive, et la levée d'ambiguïté quand deux packages chargés exportent le même nom - dplyr::filter() contre stats::filter() est la collision classique.

Garder les packages à jour

Les packages évoluent indépendamment de R, donc la mise à jour te revient :

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

Une règle peu évidente : les packages sont compilés pour une version majeure.mineure précise de R. Quand tu mets à jour R lui-même (disons de 4.3 à 4.4 - voir installer R), ton ancienne bibliothèque de packages n'est généralement pas reprise, et la solution consiste simplement à réinstaller les packages que tu utilises sous la nouvelle version. Dix minutes d'install.packages(), pas un désastre - mais ça surprend la première fois que tes scripts accueillent une installation neuve de R avec un mur d'erreurs « no package called ».

Voir ce que tu as

Trois fonctions répondent à « qu'est-ce qui est installé et où » :

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() renvoie une matrice avec une ligne par package - la colonne Version est généralement celle que tu veux. sessionInfo() est l'outil de reproductibilité : colle sa sortie dans un rapport de bug et le lecteur connaît ta version de R, ton système d'exploitation et les versions exactes de chaque package chargé. .libPaths() montre les dossiers de bibliothèques que R explore ; savoir que ça existe démystifie le « mais où est passé ce package ? » et pourquoi les droits d'administrateur comptent parfois sur les machines partagées.

Des packages à connaître

Tu n'en as pas besoin aujourd'hui, mais tu les croiseras constamment - savoir à quoi sert chacun aide à lire le code des autres :

• dplyr - les verbes de manipulation de données : filter, mutate, group_by, summarize.
• ggplot2 - le package graphique standard ; la plupart des graphiques R que tu vois en ligne sont du ggplot2.
• tidyr - remise en forme des données entre formats large et long (pivot_longer, pivot_wider).
• readr / readxl - lecture rapide de CSV et lecture de fichiers Excel respectivement.
• lubridate - des dates qui se comportent comme tu l'attends.
• stringr - manipulation de chaînes cohérente.
• data.table - un écosystème alternatif de data frames haute performance ; un dialecte différent du tidyverse, très apprécié pour les gros volumes.
• shiny - des applications web interactives écrites entièrement en R.

Les six premiers forment le cœur du tidyverse et arrivent ensemble avec install.packages("tidyverse"). Rien ne t'oblige à en utiliser un seul - R de base sait tout faire - mais c'est dans cet écosystème que vit la majorité du code R moderne.

Ce que tu retiens

• Le CRAN héberge environ 20 000 packages vérifiés ; Bioconductor et GitHub couvrent le reste.
• install.packages("nom") une fois par machine (guillemets obligatoires) ; library(nom) une fois par session, en tête du script.
• library() échoue fort - c'est bien ; require() renvoie FALSE - utile uniquement dans des tests.
• pkg::fun() utilise une fonction sans attacher le package, et résout les collisions de noms.
• update.packages() maintient tout à jour ; une mise à niveau majeure de R implique de réinstaller les packages.
• sessionInfo() est la façon de dire à quelqu'un (ou à toi plus tard) exactement sur quoi ton code a tourné.

Prochaine étape : le répertoire de travail - où R cherche les fichiers, et pourquoi c'est la première chose à vérifier quand la lecture de données échoue.