renv, rix, rv, uvr, ir: An explosion of R package and environment managers

Use case

This is a long-established package supported by Posit (creators of RStudio) used for project-local R package management.

How to use renv

renv is iterative and retrospective: you install the packages first, and then take a snapshot.

1. Install the renv package:

2. Within a project, initialize renv:

3. Install packages:

Install packages the regular way, i.e., install.packages().

When you install packages, they will be installed into a project-specific library.

4. Snapshot your library’s packages into a lock file:

This lockfile captures the exact versions of those packages:

  "R": 
    "Version": "4.4.2",
    "Repositories": [
      
        "Name": "CRAN",
        "URL": "
      
    ]
  ,
  "Packages": 
    "dplyr": 
      "Package": "dplyr",
      "Version": "1.1.4",
      "Source": "Repository",
      "Repository": "CRAN",
      "Hash": "fedd9d00c2944ff00a0e2696ccf048ec"
    ,
    "ggplot2": 
      "Package": "ggplot2",
      "Version": "3.5.1",
      "Source": "Repository",
      "Repository": "CRAN",
      "Hash": "44c6a2f8202d5b7e6c72a95ca7ea1795"
    
  

5. Iterate:

As you continue adding packages, continue snapshotting to update the lock file.

How to share using renv

When someone wants to run your project using the packages stored in its renv lockfile, they can restore the library on their machine by running renv::restore().

Some considerations

Because renv is iterative and retrospective, you can accidentally install packages that conflict with the packages that you had installed earlier.

While renv tracks your R version, it intentionally does not manage it. If you need to switch R versions, you’ll want a tool like rig. See the renv documentation for the full list of caveats.

Use case

rix operates one level up from the other tools on this list. Instead of managing packages within an R installation, rix uses Nix, a general-purpose package manager, to snapshot an entire software environment: R itself, packages, and any system-level dependencies they need.

How to use rix

rix is retrospective but in a different sense than renv. You declare the environment you want up front, and Nix builds it from scratch (pulling from a package index rather than your currently-installed library).

1. Install Nix and the rix package:

2. Declare your environment:

Write a small script (e.g., generate_env.R) describing the R version and packages you need:

library(rix)

rix(
  r_ver = "4.4.2",
  r_pkgs = c("dplyr", "ggplot2"),
  project_path = "."
)

Running this script generates a default.nix file, a plain-text description of the environment.

3. Build the environment:

Running nix-build creates the environment stored in /nix/store:

Then, you can drop into this environment interactively by running nix-shell.

From there, you can work normally by launching R, writing scripts, rendering Quarto docs, etc.

When you want to add a new package, edit generate_env.R and rerun that script to regenerate default.nix, and then run nix-build/nix-shellagain.

How to share using rix

Share the default.nix file (typically committed alongside your project). Anyone with Nix installed can rebuild the exact same environment, byte for byte, regardless of their operating system, by running nix-build or nix-shell against that file.

Some considerations

Because rix depends on Nix, there’s a bigger lift required to install and learn Nix itself. In exchange, you get reproducibility that extends beyond R packages to the R version and even system dependencies.

Use case

This is a relatively new tool by A2-ai, written in the ever-so-popular Rust language, used for project-local R package management.

It supports multiple package repositories with per-package source control (e.g., forcing a specific package to build from source vs. binary), and claims large speed improvements (20x+) over renv for installs.

rv is declarative: you write your desired packages and versions into a config file, and rv resolves the entire dependency graph upfront before installing anything.

How to use rv

1. Install rv:

rv is a standalone command-line tool, not an R package. There are a few installation instructions; see the documentation for more. I have Homebrew on my Mac, so I can run:

2. Start a new project:

Start a new project with rv init. For example, running the below creates a new folder called hello_world:

If you open up the hello_world folder, you’ll see that rv created various files and folders in your project folder:

hello_world/
  rv/
  library/
  scripts/
    activate.R
    rvr.R
  .gitignore
  .Rprofile
  rproject.toml

3. Update config file:

I don’t want to just repeat the documentation because it’s quite excellent, but essentially, you would fill in your packages as dependencies in rproject.toml:

r_version = "4.4.2"

# A list of packages to install and any additional configuration
# Examples:
    # "dplyr",
    # name = "dplyr", repository = "CRAN",
    # name = "dplyr", git = " tag = "v1.1.4",
dependencies = [
    "dplyr",
    "ggplot2"
]

4. Install packages:

Then, run rv sync to install the packages in the config file, as well as all of their dependencies:

This resolves the dependency graph and writes the exact versions to an rv.lock file, something like:

[[packages]]
name = "dplyr"
version = "1.1.4"
repository = "CRAN"
source = "Repository"
hash = "fedd9d00c2944ff00a0e2696ccf048ec"

[[packages]]
name = "ggplot2"
version = "3.5.1"
repository = "CRAN"
source = "Repository"
hash = "44c6a2f8202d5b7e6c72a95ca7ea1795"

How to share using rv

If someone wants to open your rv project, they can clone your folder (including the .toml) and then run rv init.

Some considerations

Because rv is declarative and resolves the whole dependency graph upfront, it’s less forgiving of “install whatever you need as you go” exploratory work that renv accommodates; you’re expected to know (or figure out) your dependencies before you can sync.

You may notice that rv’s rproject.toml has an r_version field, but this does not actually manage the R version. Like renv, rv does not download, install, or switch R versions for you (again, you’d want a tool like rig for that).

If you want a single tool that tracks both your R packages and R version, and can actually switch R versions for you, you may want to check out…

Use case

uvr is built by nbafrank, an independent developer. Like rv, it’s also written in Rust, and it is explicitly modeled on Python’s uv, a.k.a., the best thing to happen to the Python ecosystem in a decade.

It bundles R package management and R version management (two things that renv and rv treat separately), backed by a single lockfile (uvr.lock) that is meant to be the “source of truth” for a project.

How to use uvr

uvr, like rv, is declarative: you add packages (and optionally an R version constraint) to a manifest, and uvr resolves and locks the whole dependency graph before installing anything.

1. Install uvr:

uvr is a standalone binary, not an R package (though a companion R package, uvr-r, lets you drive it from the R console instead of the terminal).

curl -fsSL  | sh

2. Start a new project:

mkdir my-project && cd my-project
uvr init --r-version ">=4.4.2"

This creates a uvr.toml manifest in the project folder.

3. Add packages:

Each add updates uvr.toml and re-resolves uvr.lock. (uvr also supports Bioconductor and GitHub sources, e.g. uvr add DESeq2 --bioc or uvr add user/repo@main.)

4. Install everything from the lockfile:

This is what generates and keeps uvr.lock up to date, capturing both the R version and package versions, something like:

r-version = "4.4.2"

[[packages]]
name = "dplyr"
version = "1.1.4"
source = "cran"
hash = "fedd9d00c2944ff00a0e2696ccf048ec"

[[packages]]
name = "ggplot2"
version = "3.5.1"
source = "cran"
hash = "44c6a2f8202d5b7e6c72a95ca7ea1795"

5. Run scripts inside the isolated environment:

How to share using uvr

Commit uvr.toml and uvr.lock alongside your project. Someone who wants to reproduce your environment (including your pinned R version) clones the repo and runs:

--frozen will fail if the lockfile is stale.

Use case

ir operates one level down from the project-level tools. It’s built for single scripts or Quarto documents rather than whole projects. It’s a command-line tool for running portable R scripts and rendering Quarto documents whose package requirements (and optionally an R version) live inside the file itself for single-file workflows that don’t quite need a project, but still need to be easy to share and rerun later.

How to use ir

1. Install ir:

Follow the installation instructions in the repo:

curl -fsSL  | sh

2. Declare requirements in the file itself:

Add frontmatter (for .qmd/.Rmd) or a header comment (for .R scripts) listing the packages and, optionally, an R version or a Posit Package Manager snapshot date:

#!/usr/bin/env -S ir run
#| packages:
#|   - dplyr>=1.0
#|   - [email protected]
#| isolated: true
#| exclude-newer: "2025-05-15"

library(dplyr)
library(ggplot2)

mtcars |> count(cyl, gear) |> ggplot(aes(x = cyl, y = gear)) + geom_col()

---
title: My report
ir:
  packages:
    - dplyr>=1.0
    - [email protected]
  isolated: true
  exclude-newer: 2025-05-15
---

3. Run or render the file:

ir run script.R
ir render report.qmd

When you run or render the file, ir resolves the requirements, prepares cached package libraries, and launches R or Quarto with a runtime ready to use.

How to share using ir

Send the single .R or .qmd file (there’s no separate lockfile or project directory to keep track of). On first use, ir prepares its own resolver tooling in its cache, so the recipient doesn’t need to pre-install pak or renv; they can run ir run or ir render and ir takes care of resolving and caching the right packages.

Some considerations

ir is the newest tool here (first released mid-2026) and intentionally narrow in scope: it solves reproducibility for a single file, not a whole project. So, it’s a complement to, not a replacement for, renv/rix/rv/uvr when you actually do need a shared project-level environment.