Skip to contents

Choosing a setup: boosterpak and the other R environment managers

Source: vignettes/choosing-a-setup.qmd

Last checked: 2026-10-17. The comparison of tools below is based on {renv}, {rix}, rv, uvr, ir: An explosion of R package and environment managers, by Isabella Velásquez, published 2026-10-06 on R Works. That post does not mention boosterpak. The landscape changes quickly, so check the post and each tool’s own documentation before you decide.

Where boosterpak fits

boosterpak is a layer on top of {renv} and {pak}, and it requires both. In its default mode, {renv} owns the project library and renv.lock, {pak} installs packages, and boosterpak adds reusable project packs: package bundles, startup attachment rules, and helper-function files. It works at the project level. It does not manage the R version or anything outside R packages.

{rix}, rv, and uvr are not layers that boosterpak runs on top of. {rix} works at the level of the whole software environment, and boosterpak does not use it. rv and uvr each manage the project library and lockfile themselves, so they are alternatives to boosterpak’s {renv}-based layer. A project uses one approach or the other.

For existing projects, boosterpak also has an active-library mode. Set library = "active" in the [settings] table of boosters.toml, or pass library = "active" to sync() for one call. That mode installs missing packages into your current R libraries and writes no lockfile. See the getting started vignette.

Why use boosterpak

The tools in the post mostly answer one question: which package versions, and sometimes which R version or system environment, does this work use? boosterpak answers a different one: what does every project of mine start with? It does not replace the version-pinning layer. It sits on {renv} for that (in its default mode) and adds the setup that you would otherwise repeat by hand in each project:

  • Packs. A pack is a named bundle of packages, optional GitHub sources, startup attachment rules, and helper-function files. Packs can extend other packs. You build a pack once (for example with save_pack() from a set of packages you already use), move it to user scope with promote_pack(), and then add it to any project with add_pack().
  • One declared intent. boosters.toml lists the packs, extras, and exclusions the project wants. sync() installs them and writes the attach file, and {renv} records the exact versions in renv.lock.
  • Startup behavior you can inspect. The packages that attach when R starts come from a generated boosters/attach.R. status() shows each attached package and the pack behind it, so you can trim startup cost, for example in targets and crew workers. A pack can also attach its packages only in interactive sessions, which keeps them out of worker startup.
  • Helper functions that travel with the project. Pack helper files are copied into the project, and check_functions() and diff_function() show when a copy has drifted from its source.
  • Linux binary handling. On glibc Linux, when you use Posit Package Manager, boosterpak points R and {renv} at its manylinux binary URL and check_binary_repos() tells you whether you are getting binaries or compiling from source.
  • A path for older projects. upgrade_project() previews and applies the changes needed to bring an earlier boosterpak project to the current layout.

If you only need pinned package versions for one project, {renv} alone is enough, and the other tools cover wider or different ground. boosterpak pays off when you have several projects that should start from the same foundation and stay consistent as that foundation changes.

That means two questions usually decide the choice:

  1. Do you need something beyond project-level R packages, such as a pinned R version, system libraries, or a single shareable script? If so, use the tool built for that layer.
  2. If project-level packages are enough, do you want reusable setup on top of {renv}? If so, boosterpak is the layer for that.

What the post says about each tool

The post has no comparison table. For each tool it gives feature tags (Packages, R version, Environments) and places the tools at levels in its summary: {rix} snapshots the entire system environment; {renv}, rv, and uvr manage R package dependencies within a single R project; and ir handles dependencies for a single R script rather than a project. The table below restates those tags and levels in our own words.

The post does not define its tags. We read Packages as installing and pinning R packages, R version as installing or switching R itself, and Environments as capturing the wider software environment, such as system libraries. The post says {renv} and rv track an R version without managing it.

The last row is the boosterpak maintainers’ own assessment, not the post’s. It applies the same questions to boosterpak.

Tool Level Packages R version Environments Declarative or retrospective Lockfile Installed as
{renv} Project packages Yes No (records it) No Retrospective: install, then snapshot renv.lock R package
{rix} Whole software environment Yes Yes Yes Retrospective, but in a different sense than {renv}, in the post’s words: the environment is declared up front, and Nix builds it from scratch default.nix, built by Nix R package plus Nix
rv Project packages Yes No (records it) No Declarative: rproject.toml resolved before install rv.lock Standalone Rust CLI
uvr Project packages and R version Yes Yes No Declarative: uvr.toml resolved before install uvr.lock Standalone binary, optional R companion package
ir Single script or Quarto document Yes Yes, optional per file No Declarative per file: requirements in the file header None; the file is the record Standalone CLI
boosterpak (maintainers’ assessment) Project packages and startup setup, layered on {renv} and {pak} Yes, through {pak} No (records it through {renv}) No Both: boosters.toml declares intent; {renv} snapshots record exact versions renv.lock, through {renv} R package; requires {renv} and {pak}

The boosterpak row describes its default {renv} mode. Its active-library mode, selected with init(renv = "no") and library = "active" in boosters.toml, installs missing packages with {pak} into the first writable entry of .libPaths() and writes no lockfile. That mode is supported. The maintainers have not tested boosterpak together with {rix} or Nix.

The post also mentions three tools that are not in the table:

  • rig installs and switches between R versions on your machine. The post suggests it for matching a pinned R version that {renv} or rv records. Its footnote 4 notes that rig has since added project-management features, so check its current documentation.
  • devenv is a general-purpose Nix-based development environment manager. It is not specific to R.
  • rpx is named in the post, which does not describe it.

Where each tool fits

Tool Pick it when Relation to boosterpak
{renv} You want the usual install.packages() workflow with a project library and a lockfile, and no new tool. The post notes that the iterative style can install conflicting packages and that {renv} does not manage R versions. boosterpak’s default mode builds on {renv}. Add boosterpak when you want reusable packs and attach rules on top of it.
{rix} You need reproducibility beyond R packages, including R itself and system libraries, and you are willing to learn Nix. A different layer. boosterpak does not manage Nix, system libraries, or R versions. The maintainers have not tested using both together.
rv You want packages declared up front in rproject.toml and resolved before anything installs, and you accept that exploratory installs are less convenient. A different workflow. boosterpak requires {renv} and {pak}, and rv projects do not use boosterpak’s default {renv}-based flow as they are.
uvr You want one tool for the R version and the packages, with one lockfile, uvr.lock. A different workflow, with the same caveat as rv. boosterpak does not manage the R version.
ir You share one R script or Quarto document whose requirements live in the file. The post describes ir as intentionally narrow and as a complement to project tools. A complement at a different level. boosterpak works per project.
rig You need to install or switch between R versions on one machine. No interaction. rig is a standalone R version manager. boosterpak does not call it, and does not install or switch R.

Decision guide

The flowchart is a rough guide written by the boosterpak maintainers. It is not from the post, which does not recommend one tool over another.

flowchart TD
  A([What do you need to pin?]) --> B{Single script or Quarto file?}
  B -->|Yes| IR(["ir: requirements in the file"])
  B -->|No| C{Whole system, including R and system libraries?}
  C -->|Yes| RIX(["rix: Nix environment"])
  C -->|No| D{Need the R version managed too?}
  D -->|Yes| UVR(["uvr: packages and R version"])
  D -->|No| E{Declare everything up front?}
  E -->|Yes| RV(["rv: rproject.toml and rv.lock"])
  E -->|No| F(["renv: project library and renv.lock"])
  F --> G{Reusable packs and startup rules across projects?}
  G -->|Yes| BP(["Add boosterpak on top of renv and pak, or use its active-library mode"])
  G -->|No| R1(["Stay with renv"])

  classDef userAction fill:#e8f3ff,stroke:#1f6feb,color:#0b1f3a;
  classDef packageAction fill:#f6f8fa,stroke:#6e7781,color:#24292f;
  class A,B,C,D,E,G userAction;
  class IR,RIX,UVR,RV,F,BP,R1 packageAction;

The R version question appears in the flowchart only for uvr, which manages R versions. rv and {renv} do not manage R versions. If you need a specific R version with either of them, install that version with rig, a separate tool. boosterpak has no interaction with rig.

Pick boosterpak when

  • You already use {renv}, or plan to, and want each project to match a declared set of packages, startup attachment, and helper functions.
  • You reuse the same setup across projects and want it captured as a pack that you can review, promote, and add to another project with add_pack().
  • Your team commits renv.lock and you want the Linux binary handling described in the getting started vignette.

Do not pick boosterpak when

  • You need the R version managed or switched. {renv} records it but does not change it. Use uvr, which manages the R version together with the packages. rig switches R versions, but boosterpak does not use it.
  • You need system libraries or the whole software environment captured. Use {rix}.
  • Your work is one file. Use ir.
  • Your project already runs on rv or uvr. Their own workflows cover the same ground. boosterpak’s default flow would add a second project library and lockfile to the same project.

The R code in boosterpak does not call or depend on {rix}, rv, uvr, ir, or rig, and it does not use Nix. The maintainers have not tested boosterpak together with {rix} or Nix.

Sources