Pacotes do R: install.packages(), library() e o CRAN

O Que É um Pacote

Um pacote é um conjunto de funções, documentação e às vezes dados que estende o R. O R base te dá vetores, modelos e gráficos; os pacotes te dão todo o resto - e esse "todo o resto" é enorme. O CRAN (Comprehensive R Archive Network) hospeda cerca de 20 mil pacotes, cada um verificado pelos testes de submissão do CRAN antes de ser publicado. Esse repositório é a principal razão pela qual o R segue competitivo para trabalho com dados: seja qual for a análise, alguém provavelmente já a empacotou.

O CRAN não é a única fonte - o Bioconductor hospeda o ecossistema de bioinformática, e muitos pacotes em desenvolvimento moram no GitHub (instaláveis com remotes::install_github()) - mas, como iniciante, você pode tratar o CRAN como o padrão e os outros como coisas que vai encontrar quando um README mandar.

Um punhado de pacotes vem com o próprio R (stats, utils, graphics e companhia) e carrega automaticamente - é por isso que mean() e plot() simplesmente funcionam. Todo o resto segue o ritual de dois passos abaixo.

install.packages() Uma Vez, library() a Cada Sessão

Essa é a confusão nº 1 de iniciantes, então aqui vai da forma mais nítida possível. Colocar um pacote para funcionar são duas ações diferentes com dois tempos de vida diferentes:

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") é como comprar um livro: você faz isso uma vez, e daí em diante ele fica na sua estante (seu disco). Repare nas aspas - você está passando o nome como uma string.
• library(dplyr) é como tirar o livro da estante: você faz isso no começo de cada sessão do R (na prática, no topo de cada script). Aqui não precisa de aspas - library() é especial e aceita o nome sem elas (library("dplyr") também funciona, se você preferir consistência).

Os dois modos de falha te dizem qual passo você pulou. Error: there is no package called 'dplyr' vindo de library() significa que ele nunca foi instalado. Error: could not find function "filter" (ou "%>%") no meio de um script significa que o pacote está instalado mas esta sessão nunca o carregou. Colocar toda chamada library() bem no topo do script - e não espalhada por ele - torna a segunda falha visível no primeiro segundo, e serve também como uma lista das dependências do script. Instalar o tidyverse funciona do mesmo jeito: install.packages("tidyverse") uma vez, library(tidyverse) por sessão, o que carrega dplyr, ggplot2 e o resto do conjunto principal em uma linha.

O que você não deve fazer é deixar install.packages() dentro de um script que você roda repetidamente ou compartilha - ele rebaixa tudo a cada execução e pode surpreender quem o executar. Instalação é um ato de console; carregamento é um ato de script.

require() e pkg::fun()

require() parece um sinônimo de library(), e usá-lo assim, erroneamente, é comum. A diferença está no que acontece quando o pacote não existe: library() para com um erro; require() imprime um aviso, retorna FALSE e deixa o script continuar - normalmente para morrer vinte linhas depois com um confuso "could not find function" em vez da honesta mensagem "no package called". Para carregar dependências, use library(): falhar alto no topo é um recurso. require() se justifica apenas em verificações condicionais, em que o valor de retorno é o ponto:

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

Há também uma forma de usar um pacote sem carregá-lo de jeito nenhum: o operador :: chama uma função pelo seu endereço completo, pacote::funcao(). O pacote precisa estar instalado, mas nada é anexado à sua sessão:

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 é carregado automaticamente de qualquer forma, então sd() puro também funciona - mas a sintaxe é a mesma para qualquer pacote instalado.) :: brilha em dois lugares: chamadas pontuais em que uma linha library() inteira é exagero, e desambiguação quando dois pacotes carregados exportam o mesmo nome - dplyr::filter() vs stats::filter() é a colisão clássica.

Mantendo os Pacotes Atualizados

Pacotes evoluem independentemente do R, então atualizar é responsabilidade sua:

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

Uma regra não óbvia: pacotes são construídos contra uma versão maior.menor específica do R. Quando você atualiza o próprio R (digamos da 4.3 para a 4.4 - veja instalando o R), sua biblioteca antiga de pacotes geralmente não é levada junto, e a solução é simplesmente reinstalar os pacotes que você usa sob a nova versão. Dez minutos de install.packages(), não um desastre - mas surpreende as pessoas na primeira vez em que seus scripts saúdam uma instalação nova do R com uma parede de erros "no package called".

Vendo o Que Você Tem

Três funções respondem "o que está instalado e onde":

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() retorna uma matriz com uma linha por pacote - a coluna Version normalmente é o que você quer. sessionInfo() é a ferramenta de reprodutibilidade: cole sua saída em um relatório de bug e quem ler saberá sua versão do R, o sistema operacional e as versões exatas de todo pacote carregado. .libPaths() mostra as pastas de biblioteca que o R pesquisa; saber que isso existe desmistifica o "para onde foi mesmo aquele pacote?" e por que direitos de administrador às vezes importam em máquinas compartilhadas.

Pacotes Que Vale a Pena Conhecer

Você não precisa deles hoje, mas vai encontrá-los o tempo todo - saber para que serve cada um ajuda a ler o código dos outros:

• dplyr - os verbos de manipulação de dados: filter, mutate, group_by, summarize.
• ggplot2 - o pacote gráfico padrão; a maioria dos gráficos de R que você vê online é ggplot2.
• tidyr - remodelagem de dados entre formatos largo e longo (pivot_longer, pivot_wider).
• readr / readxl - leitura rápida de CSV e leitura de arquivos Excel, respectivamente.
• lubridate - datas que se comportam como você espera.
• stringr - manipulação consistente de strings.
• data.table - um ecossistema alternativo de data frames de alto desempenho; um dialeto diferente do tidyverse, adorado para grandes volumes de dados.
• shiny - aplicações web interativas escritas inteiramente em R.

Os seis primeiros são o núcleo do tidyverse e chegam juntos com install.packages("tidyverse"). Não há obrigação de usar nenhum deles - o R base dá conta de tudo isso - mas o ecossistema é onde vive a maior parte do R moderno.

O Que Você Leva Daqui

• O CRAN hospeda ~20 mil pacotes revisados; Bioconductor e GitHub cobrem o resto.
• install.packages("nome") uma vez por máquina (aspas obrigatórias); library(nome) uma vez por sessão, no topo do script.
• library() falha alto - o que é bom; require() retorna FALSE - útil apenas dentro de verificações.
• pkg::fun() usa uma função sem anexar o pacote, e resolve colisões de nomes.
• update.packages() mantém tudo em dia; uma atualização maior do R significa reinstalar pacotes.
• sessionInfo() é como você conta a alguém (ou ao seu eu futuro) exatamente em que seu código rodou.

A seguir: o diretório de trabalho - onde o R procura arquivos, e por que essa é a primeira coisa a checar quando a leitura de dados falha.