Paquetes de R: install.packages(), library() y CRAN

Qué es un paquete

Un paquete es un conjunto de funciones, documentación y a veces datos que extiende R. R base te da vectores, modelos y gráficos; los paquetes te dan todo lo demás - y ese "todo lo demás" es enorme. CRAN (la Comprehensive R Archive Network) aloja unos 20.000 paquetes, cada uno de ellos verificado contra las pruebas de envío de CRAN antes de publicarse. Ese repositorio es la principal razón por la que R sigue siendo competitivo para el trabajo con datos: sea cual sea el análisis, probablemente alguien lo haya empaquetado.

CRAN no es la única fuente - Bioconductor aloja el ecosistema de bioinformática y muchos paquetes en desarrollo viven en GitHub (instalables con remotes::install_github()) -, pero como principiante puedes tratar CRAN como el valor por defecto y los demás como cosas que encontrarás cuando un README te lo indique.

Un puñado de paquetes vienen con el propio R (stats, utils, graphics y compañía) y se cargan automáticamente - por eso mean() y plot() simplemente funcionan. Todo lo demás sigue el ritual de dos pasos de abajo.

install.packages() una vez, library() en cada sesión

Esta es la confusión número 1 de quien empieza, así que aquí va con la máxima claridad posible. Poner en marcha un paquete son dos acciones distintas con dos duraciones distintas:

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") es como comprar un libro: lo haces una vez y a partir de entonces se queda en tu estantería (tu disco). Fíjate en las comillas - estás pasando el nombre como una cadena.
• library(dplyr) es como coger el libro de la estantería: lo haces al principio de cada sesión de R (en la práctica, al principio de cada script). Aquí no hacen falta comillas - library() es especial y acepta el nombre suelto (library("dplyr") también funciona, si prefieres la coherencia).

Los dos modos de fallo te dicen qué paso te saltaste. Error: there is no package called 'dplyr' desde library() significa que nunca se instaló. Error: could not find function "filter" (o "%>%") a mitad de un script significa que el paquete está instalado pero esta sesión nunca lo cargó. Poner todas las llamadas a library() justo al principio del script - y no repartidas por él - hace que el segundo fallo sea visible en el primer segundo, y de paso sirve como lista de dependencias del script. Instalar tidyverse funciona igual: install.packages("tidyverse") una vez, library(tidyverse) por sesión, lo que carga dplyr, ggplot2 y el resto del conjunto principal en una línea.

Lo que no deberías hacer es dejar install.packages() dentro de un script que ejecutes repetidamente o que compartas - vuelve a descargar en cada ejecución y puede sorprender a quien lo ejecute. La instalación es un acto de consola; la carga es un acto de script.

require() y pkg::fun()

require() parece un sinónimo de library(), y usarla mal como tal es habitual. La diferencia está en lo que ocurre cuando falta el paquete: library() se detiene con un error; require() imprime un aviso, devuelve FALSE y deja que el script continúe - normalmente para morir veinte líneas después con un confuso "could not find function" en vez del honesto "no package called". Para cargar dependencias, usa library(): fallar ruidosamente al principio es una ventaja. require() se gana el sueldo solo en comprobaciones condicionales, donde su valor de retorno es lo importante:

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

También hay una forma de usar un paquete sin cargarlo en absoluto: el operador :: llama a una función por su dirección completa, paquete::funcion(). El paquete debe estar instalado, pero no se adjunta nada a tu sesión:

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 se carga automáticamente de todos modos, así que sd() a secas también funciona - pero la sintaxis es la misma para cualquier paquete instalado.) :: brilla en dos sitios: llamadas puntuales donde una línea entera de library() es excesiva, y la desambiguación cuando dos paquetes cargados exportan el mismo nombre - dplyr::filter() frente a stats::filter() es la colisión clásica.

Mantener los paquetes al día

Los paquetes evolucionan de forma independiente de R, así que actualizarlos es cosa tuya:

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

Una regla no obvia: los paquetes se compilan contra una versión mayor.menor concreta de R. Cuando actualizas el propio R (digamos de 4.3 a 4.4 - mira instalar R), tu biblioteca de paquetes antigua generalmente no se traslada, y la solución es simplemente reinstalar los paquetes que uses bajo la nueva versión. Diez minutos de install.packages(), no un desastre - pero sorprende la primera vez que tus scripts saludan a una instalación fresca de R con un muro de errores "no package called".

Ver lo que tienes

Tres funciones responden a "qué está instalado y dónde":

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() devuelve una matriz con una fila por paquete - la columna Version suele ser lo que quieres. sessionInfo() es la herramienta de reproducibilidad: pega su salida en un informe de error y quien lo lea sabrá tu versión de R, tu sistema operativo y las versiones exactas de todos los paquetes cargados. .libPaths() muestra las carpetas de biblioteca en las que busca R; saber que existe desmitifica el "¿dónde fue a parar ese paquete?" y por qué a veces importan los permisos de administrador en máquinas compartidas.

Paquetes que conviene conocer

Hoy no necesitas estos, pero te los encontrarás constantemente - saber para qué sirve cada uno te ayuda a leer el código de los demás:

• dplyr - los verbos de manipulación de datos: filter, mutate, group_by, summarize.
• ggplot2 - el paquete gráfico estándar; la mayoría de los gráficos de R que ves en internet son ggplot2.
• tidyr - reorganizar datos entre formatos ancho y largo (pivot_longer, pivot_wider).
• readr / readxl - lectura rápida de CSV y lectura de archivos de Excel, respectivamente.
• lubridate - fechas que se comportan como esperas.
• stringr - manipulación coherente de cadenas.
• data.table - un ecosistema alternativo de data frames de alto rendimiento; un dialecto distinto del tidyverse, adorado para grandes volúmenes de datos.
• shiny - aplicaciones web interactivas escritas enteramente en R.

Los seis primeros son el núcleo del tidyverse y llegan juntos con install.packages("tidyverse"). No hay ninguna obligación de usar ninguno de ellos - R base puede hacerlo todo -, pero el ecosistema es donde vive la mayor parte del R moderno.

Lo que te llevas

• CRAN aloja unos 20.000 paquetes revisados; Bioconductor y GitHub cubren el resto.
• install.packages("nombre") una vez por máquina (comillas obligatorias); library(nombre) una vez por sesión, al principio del script.
• library() falla ruidosamente - bien; require() devuelve FALSE - solo útil dentro de comprobaciones.
• pkg::fun() usa una función sin adjuntar el paquete y resuelve las colisiones de nombres.
• update.packages() mantiene todo al día; una actualización mayor de R implica reinstalar los paquetes.
• sessionInfo() es como le cuentas a alguien (o a tu yo futuro) exactamente sobre qué se ejecutó tu código.

Lo siguiente: el directorio de trabajo - dónde busca R los archivos y por qué es lo primero que hay que comprobar cuando falla la lectura de datos.