[[R]] のパッケージ管理では、ツール (インストーラー・言語サーバー・[[Quarto]] エンジン等) はグローバルに、分析ライブラリ ([[tidyverse]] など) はプロジェクト単位の [[renv]] に分けて入れる。 こうすると、分析の依存関係を `renv.lock` に閉じ込められ、プロジェクト間の干渉も避けられる。 ## グローバルに入れるパッケージ | パッケージ | 役割 | グローバルに入れる理由 | | ---------------- | ------------------------------------------------ | ------------------------------------------- | | `pak` | 高速・並列なパッケージインストーラ | `renv` のバックエンドとしても使う基盤ツール | | `renv` | プロジェクトごとの依存固定 (lockfile 駆動) | 各プロジェクトを有効化するために必要 | | `knitr` | Quarto / R Markdown のコードチャンク実行エンジン | Quarto が R を呼ぶたびに必要 | | `rmarkdown` | Quarto の HTML レンダリングで内部利用 | Quarto の preview / render に必須 | | `languageserver` | Positron / VS Code の R 言語サーバー | エディタの補完・定義ジャンプ用 | > [!note] > `pak` は他のパッケージをインストールするためのツールなので、`pak` 自身を `pak` でインストールできない。最初の 1 回だけ `install.packages()` で取得する。 ## グローバルに入れないもの `tidyverse` / `dplyr` / `ggplot2` などの分析ライブラリはグローバルに入れず、プロジェクトごとに `renv::install()` で導入する。`data.table` / `arrow` / `DBI` も同様の方針で扱う。 ## 関連ノート - **[応用]** [[rpj コマンドで R + Quarto + renv の分析プロジェクトを Positron で立ち上げる]]: 分離方針を自作の `rpj` コマンドで新規プロジェクト作成時に自動適用する実装例 - **[対比]** [[mise と uv で Python をグローバルとプロジェクトで使い分ける]]: 同じ「グローバル / プロジェクト分離」問題を Python の mise + uv で解いた姉妹ケース - **[派生]** [[dotfiles ではインストール対象を宣言的な設定ファイルで管理する]]: Brewfile で宣言的にインストール対象を管理する設計を、R のグローバルパッケージにも同じ形で適用した同根のパターン