Reproducibility: renv, Git, and Projects

An analysis is reproducible if someone else — or you, in a year — can rerun it and get the same results. Three tools do most of the work.

renv — lock package versions

Packages change. Code that works with today's dplyr might behave differently with next year's. renv gives each project its own library of packages and records their exact versions:

renv::init()       # set up renv for this project
# ... install and use packages as normal ...
renv::snapshot()   # record exact versions in renv.lock

Someone opening the project later runs:

renv::restore()    # install exactly the recorded versions

Commit renv.lock to version control. It's a small text file listing every package and version the project uses.

Git — track every change

Git records the history of your project's files, so you can see what changed, when, and why — and undo mistakes. RStudio has a built-in Git pane, and usethis sets it up:

usethis::use_git()
usethis::use_github()

Commit your scripts, Quarto documents, and renv.lock. Don't commit large data files, generated output, or secrets — list them in .gitignore.

Randomness and environment

• Call set.seed() before anything random: sampling, simulation, cross-validation, random forests.
• Record your session with sessionInfo() at the end of reports — the R version, operating system, and loaded package versions.
• Keep secrets (API keys, passwords) in a .Renviron file that isn't committed, and read them with Sys.getenv().

Pipelines with targets

For larger analyses, the targets package defines the analysis as a pipeline of steps — import, clean, model, report — and reruns only the steps whose code or data changed. It saves time and guarantees that results match the current code.

A checklist

• [ ] Everything runs top to bottom in a fresh R session.
• [ ] Raw data is never edited by hand.
• [ ] Paths are relative to the project.
• [ ] Package versions are locked with renv.
• [ ] Random steps use a seed.
• [ ] The project is under version control.