develop with renv, test without

[d-morrison]

can and should we configure the repo so that developers working in interactive sessions in the repo (including coding agents) use renv, but the R-CMD-CHECK and test-coverage CI workflows do not use renv? that way, all developers are on the same page, but we still check how the package performs in different R versions and with the latest CRAN packages? what's the usual approach?

[d-morrison]

@claude

[claude]

Claude finished @d-morrison's task in 2m 8s —— View job

---

Analysis: develop with renv, test without

• Gather context (existing CI workflows, renv setup, .Rprofile)
• Answer the question

---

Short answer: Yes, this is the standard approach — and the repo is already halfway there.

Here's the current state and what each option looks like:

---

Current repo state

• renv.lock exists (pinned to R 4.5.2, ~many packages)
• No renv/activate.R — renv is NOT auto-activated for local sessions
• .Rprofile sets locale and loads devtools in interactive sessions, but does not source renv
• CI (R-CMD-check.yaml, test-coverage.yaml) uses r-lib/actions/setup-r-dependencies@v2, which installs from DESCRIPTION — already renv-free

So CI already does the right thing. The gap is the local side: renv.lock exists for reference but isn't wired up to auto-activate.

---

The standard approach

The widely-used pattern (adopted by Posit/tidyverse and many CRAN packages) is:

Local/interactive development: renv is active — all developers (and coding agents via copilot-setup-steps.yml) get the locked environment automatically.

CI (R-CMD-check, test-coverage): renv is disabled — packages are resolved fresh from DESCRIPTION + CRAN, so you catch regressions against oldrel, devel, and updated upstream packages.

---

What needs to change to implement this

1. Activate renv for local development

Run once locally:

renv::init(bare = TRUE)   # or just renv::init() to snapshot current state

This creates:

• renv/activate.R — the bootstrap script (commit this)
• renv/.gitignore — excludes the library folder from git (commit this)
• Appends source("renv/activate.R") to .Rprofile

Then update .Rprofile to keep the existing content and add the renv source call:

# existing content ...
message("starting project-specific .Rprofile")
Sys.setlocale(category = "LC_COLLATE", locale = "en_US.UTF-8")
if (interactive()) {
  suppressMessages(require(devtools))
}
message("ending project-specific .Rprofile")

# renv autoloader (added by renv::init())
source("renv/activate.R")

2. Disable renv in CI workflows

Add one env variable to R-CMD-check.yaml and test-coverage.yaml:

env:
  GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
  R_KEEP_PKG_SOURCE: yes
  RENV_CONFIG_AUTOLOADER_ENABLED: 'FALSE'   # <-- add this

This prevents renv's autoloader from intercepting the R session before setup-r-dependencies@v2 installs from DESCRIPTION.

Why not just rely on the absence of renv/activate.R in CI? Once you commit renv/activate.R, the autoloader runs on every R startup in the project directory — including in CI runners — unless explicitly suppressed. The env var is the clean suppression mechanism renv provides for exactly this use case.

3. Copilot/coding-agent setup (copilot-setup-steps.yml)

The Copilot setup workflow already uses setup-r-dependencies@v2. If you want coding agents to also use the renv environment (so they're on the same page as human developers), you have two options:

• Keep as-is (DESCRIPTION-based) — simpler, agents get latest CRAN like CI
• Switch to renv — add an renv::restore() step (or use the r-lib/actions/setup-renv@v2 action) so agents get the same pinned packages as local devs

The copilot-setup-steps.yml purpose suggests option 2 (parity with local dev) is the intent.

---

Decision summary

Environment	renv?	How
Local interactive session	✅ yes	renv/activate.R + .Rprofile
Copilot/coding agent	optional	add renv::restore() to setup workflow
R-CMD-check	❌ no	RENV_CONFIG_AUTOLOADER_ENABLED: 'FALSE' + setup-r-dependencies@v2
test-coverage	❌ no	same

---

I can implement steps 1–2 (and optionally step 3) if you'd like. The workflow file changes would require you to have write access to .github/workflows/ — I cannot modify those files directly due to GitHub App permission constraints, but I can prepare the .Rprofile and renv/ side of the changes.