Man is a tool-using animal. Without tools he is nothing, with tools he is all.
Thomas Carlyle, Sartor Resartus (1831)
NoteSources
Adapted from author’s lecture notes and supporting materials for a graduate practicum in biostatistics.
5.1 Prerequisites
Answer the following questions to see if you can bypass this chapter. You can find the answers at the end of the chapter in Section 5.17.
When you install a new R package on your workstation, where does R store the compiled binary by default, and how would you check that location?
What is a ‘dotfile’, and name three commonly dotfiled tools a biostatistician might configure.
How does an integrated development environment like RStudio differ from a terminal-plus-editor combination such as tmux + Neovim, and what tradeoffs does each impose?
5.2 Learning objectives
By the end of this chapter you should be able to:
Install and configure R, Quarto, Git, and a choice of editor on a new workstation, on Mac, Linux, or Windows.
Reason about where R looks for packages (.libPaths()) and why project-level libraries matter.
Version-control your personal configuration (dotfiles) and sync it across machines.
Choose between RStudio and a terminal workflow for a given task.
Set sensible defaults in .Rprofile without breaking reproducibility.
5.3 Orientation
A workstation is the one piece of infrastructure in this book that nobody will ever ask you about. No reviewer inspects it, no funder requires it, and no collaborator sees it. It is therefore the piece most likely to be left in whatever state it arrived in, and the piece whose defects are hardest to attribute, because a poorly configured machine does not announce itself. It expresses itself as friction: a path that works here and not there, a package that is a different version than you thought, a project that takes twenty minutes to resume because the last session’s state lived in your head. Each is small enough to absorb, which is exactly why they accumulate for years.
We shall build in this chapter what we would call the minimum viable workstation of a professional biostatistician in 2026. The word to notice is ‘minimum’. The goal is not a comfortable machine, which is a matter of taste this book has no standing to legislate, but a legible one: a configuration that is written down, restorable, and separable from the projects that run on it.
The goal is a workstation where: (1) the analysis you run on Tuesday produces the same result on Wednesday, (2) the analysis you run at home produces the same result as in the office, (3) the configuration is reproducible from a git checkout if the laptop dies. None of this is glamorous; all of it is foundational.
5.4 The statistician’s contribution
A workstation is configured once and then lived in for years, which is why its small decisions compound. These are the ones worth making deliberately rather than by default:
Pin the foundational toolchain. A specific version of R, Quarto, and the rendering engine; documented and restorable. Casual updates are how reproducibility breaks silently. rig (on macOS) and Docker (Chapter 12) make multiple R versions easy to maintain side by side.
Keep .Rprofile minimal. Anything you put in .Rprofile runs at startup and changes the behavior of every session. A heavy .Rprofile (loading tidyverse, setting global options, defining helpers) makes your sessions different from a colleague’s, and breaks any script that does not explicitly load what it needs. Project-local .Rprofile is fine; user-level should be nearly empty.
Editor familiarity matters more than editor choice. RStudio, VS Code, Neovim, Emacs all work for biostatistics. Pick one and learn its shortcuts. The productivity gain from fluency in your tool of choice exceeds the gain from switching tools.
Version-control your configuration. Your dotfiles are the part of your workstation worth restoring after a crash. Putting them in git makes restoration trivial; not doing so makes a new laptop a multi-day project.
These habits are invisible when present and devastating when absent.
5.5 Installing R and Quarto
On macOS with Homebrew:
# system R via the official installer or rigbrew install --cask r# better: rig manages multiple R versionsbrew install r-lib/rig/rigrig install release # latest stablerig install 4.4.0 # specific versionrig default 4.4.0
rig is the modern way to manage R on macOS. Multiple versions side by side, fast switching, no PATH games.
For the latest version, add the CRAN apt repository (see cran.r-project.org/bin/linux/ubuntu/).
On Windows, install from cran.r-project.org and RStudio from posit.co/download/rstudio-desktop/. Most biostatistics workflows on Windows go through RStudio.
Quarto from quarto.org/docs/get-started/. The installer handles all platforms; pin to a specific version for reproducibility:
# verify versionquarto--version# in a project's _quarto.yml, optionally pin# format:# html:# ...# quarto: 1.5.55
Git is preinstalled on Linux, available in Xcode Command Line Tools on macOS (xcode-select --install), and from git-scm.com/download/win on Windows.
After installation, configure git:
git config --global user.name "Your Name"git config --global user.email "you@example.com"git config --global core.editor "code --wait"# or your editorgit config --global init.defaultBranch main
5.6 Choosing an editor
Take the conclusion first, because it is the opposite of what the length of this section implies: the choice matters much less than the fluency, and the productivity gained by knowing one editor thoroughly exceeds anything available by switching to a better one. All four options below are used professionally in biostatistics, all four are adequate, and a year spent shallowly in three of them is worse than a year spent deeply in any one.
What the choice does turn on is not quality but fit along two axes: whether your work is R-only or spans several languages, and whether it happens on your own machine or on a server you reach over SSH. The descriptions below are organized around those two questions rather than around features.
RStudio is the standard for R-only work. Integrated IDE: editor, console, environment, plots, help, Git pane in one window. Maintained by Posit; bullet-proof for the R workflow.
When to choose: R is your primary language; you want zero-setup interactive work; you teach or collaborate with people who use RStudio.
VS Code with the R extension. Modern editor, excellent multi-language support, great for projects that span R and Python or work over SSH (VS Code Remote).
When to choose: You work in multiple languages; you edit on a remote server; you appreciate Microsoft’s ecosystem (Copilot, GitHub integration).
Neovim with an R plugin. The keyboard-driven modal editor. Highly customizable, fast, works over SSH without modification. Steep learning curve. The capability that makes it viable for analysis rather than merely for editing is a link to a live R session: R-Nvim is the established choice, and the in-house zzvim-R is the lighter one used in this book’s own development, sending the current line, a visual selection, or a whole Quarto chunk to an embedded terminal and rendering the document without leaving the editor.
When to choose: You already use vi/Neovim for other languages; you do most of your work over SSH; keyboard fluency matters more than visual polish.
Positron (Posit’s newer IDE, stable releases through 2026 with some components still labeled experimental). Aimed at being VS Code’s R-and-Python competitor; produced by the same team that makes RStudio. Worth watching but not yet ubiquitous.
The dominant choice in academic biostatistics remains RStudio. The fastest-growing alternative is VS Code. Pick one and become fluent; switching costs add up.
5.7 Shells and terminal setup
For Mac and Linux, zsh is the default modern shell. Configure it with a ~/.zshrc:
# minimal zshrc# historyHISTFILE=~/.zsh_historyHISTSIZE=10000SAVEHIST=10000setopt SHARE_HISTORY HIST_IGNORE_DUPS# prompt: starship is a good defaulteval"$(starship init zsh)"# R-friendly aliasesalias R='R --no-save'alias r='R --quiet --no-save'# editorexportEDITOR='code'# brew completions on macOS[-f /opt/homebrew/etc/profile.d/bash_completion.sh ]&&\source /opt/homebrew/etc/profile.d/bash_completion.sh
starship (starship.rs) gives a clean, fast prompt with git integration. Install with brew install starship.
tmux is worth learning if you SSH into servers: persistent sessions that survive disconnections, multiple panes, named windows. A minimal .tmux.conf:
set -g default-terminal "screen-256color"
set -g mouse on
set -g status-position top
bind-key C-a send-prefix
unbind C-b
set -g prefix C-a
For most local biostatistics work, you do not need tmux; RStudio’s session management suffices.
5.8 R package libraries
Almost every ‘it works on my machine’ report about a missing or wrong-version package resolves to one question: which library did R actually look in? Figure 5.1 is the search order, and the thing to notice is that renv works by prepending to it rather than by replacing anything.
flowchart TD
Q["library(dplyr)"] --> A{"project renv library<br/><i>present and active?</i>"}
A -->|"yes"| B["renv/library/...<br/><i>project-pinned version</i>"]
A -->|"no"| C{"user library"}
C -->|"found"| D["~/Library/R/...<br/><i>whatever you last installed</i>"]
C -->|"not found"| E["site and system libraries<br/><i>whatever the admin installed</i>"]
B --> F["first match wins"]
D --> F
E --> F
Figure 5.1: The library search path. R takes the first match it finds, and installs into the first entry. Activating renv prepends the project library, which is why the same install.packages() call lands in different places depending on where you ran it.
R looks for packages in the directories returned by .libPaths():
This is exactly what renv does: each project has its own package library, isolated from other projects and from your user library. (Chapter 8 covers renv in depth.)
The recommended pattern is:
User library has a small set of packages used across projects: usethis, devtools, rmarkdown, maybe tidyverse. Update when convenient.
Project libraries (under renv) hold the version-pinned dependencies for reproducibility.
NoteCheck your understanding: where does install go?
Question. You run install.packages("dplyr") from inside a project that has renv active. Where does it install?
Answer.
Into the project’s renv/library/ directory, not the user library. renv modifies .libPaths() so that the first entry is the project library. install.packages() installs to the first entry. The lock file (renv.lock) is updated to record the new package and its version. This isolation is exactly the point of renv: a package update inside one project does not affect any other project’s packages.
5.9.Rprofile: minimal and project-local
Avoid putting analysis code in user-level .Rprofile. Things that are fine:
# ~/.Rprofile# friendlier defaultsoptions(repos =c(CRAN ="https://cloud.r-project.org/"),prompt ="R> ",continue =" + ",digits =7,warnPartialMatchArgs =TRUE,warnPartialMatchAttr =TRUE,warnPartialMatchDollar =TRUE)# only attach interactively (not in scripts or knitting)if (interactive()) {suppressMessages(require(devtools))}
Things to avoid in user-level .Rprofile:
library(tidyverse), makes scripts depend on it silently.
Defining global helper functions, breaks reproducibility for collaborators.
Setting options(stringsAsFactors = FALSE), harmless in R 4.0+, but a sign of muscle memory from older versions.
Project-level .Rprofile is different: anything in there is part of the project, and runs for anyone who opens the project. renv itself uses a project .Rprofile to activate the project library. Anything else in the project .Rprofile should be deliberate.
5.10 Dotfiles in version control
Your .zshrc, .gitconfig, .Rprofile, init.vim (Neovim), and editor settings are configuration that you will want on every machine you use. Version-controlling them prevents ‘I forgot what I changed last time’.
Use GNU stow (or chezmoi, or yadm) to symlink the dotfiles into the right places:
cd ~/dotfilesstow zsh git R nvim # symlinks ~/.zshrc -> ~/dotfiles/zsh/.zshrc, etc.
Push the dotfiles repository to GitHub. On a new machine:
git clone https://github.com/you/dotfiles.git ~/dotfilescd ~/dotfilesstow zsh git R nvim
Two minutes after cloning, your environment is restored.
Sensitive content (API keys, work-specific config) goes in a separate private repository or is kept out of the public dotfiles entirely. .gitignore your secrets.
5.11 Fonts and readability
Programming fonts that distinguish similar characters (0/O, 1/l/I) and support ligatures (rendering >= as a single glyph) are easy on the eyes:
Fira Code, the original ligature font; widely supported.
Source Code Pro, Adobe’s open-source choice; no ligatures.
For terminal use specifically, Nerd Fonts patch common programming fonts with extra glyphs for status-line icons, used by tools like starship.
brew install --cask font-jetbrains-mono-nerd-font
Configure your terminal and editor to use it. Set your RStudio code font in Tools → Global Options → Appearance.
5.12 Worked example: a fresh-laptop setup script
#!/usr/bin/env bash# fresh-mac.sh: bootstrap a new macOS workstation# Homebrew/bin/bash-c"$(curl-fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"# core toolsbrew install git tmux starship stowbrew install --cask jetbrains-mono r rstudio quarto# multi-version R via rigbrew install r-lib/rig/rigrig install release# clone and apply dotfilesgit clone https://github.com/you/dotfiles.git ~/dotfilescd ~/dotfiles &&stow zsh git R nvim# install commonly-used global R packagesRscript-e'install.packages(c("renv", "usethis", "devtools", "remotes", "rmarkdown"))'echo"Setup complete. Reboot recommended."
A 30-minute one-time investment that rebuilds your workstation from scratch. Refine each time you set up a new machine; your future-self thanks you.
5.13 Collaborating with an LLM on workstation setup
LLMs handle setup recipes well; they sometimes omit platform-specific gotchas.
Prompt 1: drafting a setup script. Specify the OS and ask: ‘write a bootstrap script that installs R, Quarto, RStudio, git, my dotfiles, and a sensible R package set.’
What to watch for. Platform mismatch (the LLM generates an Ubuntu script when you said macOS). Path assumptions (/usr/local/... vs /opt/homebrew/... on Apple Silicon).
Verification. Run on a clean VM. Adjust until clean runs succeed.
Prompt 2: diagnosing R startup issues. Paste an error message or the output of traceback() and ask: ‘is this an .Rprofile issue, a path issue, or something else?’
What to watch for. Most R startup issues are .Rprofile doing something unexpected, or a stale .Rhistory. The LLM should know this. If the diagnosis is generic, ask for specifics.
Verification. Run R with --vanilla (skipping .Rprofile) to isolate.
Prompt 3: configuring a new editor. Describe what you want from the editor (Neovim with R support, VS Code with Python plus R, etc.) and ask for a config.
What to watch for. The output is usually a starting point. Test it; iterate.
Verification. Open a real file and use the editor for a half-hour task. Adjust based on friction.
5.14 Principle in use
Three habits define a defensible workstation:
Pin the foundational toolchain. R, Quarto, key packages. Don’t update casually; update deliberately per project.
Version-control your dotfiles. They are your workstation’s identity, restorable from a clone.
Keep .Rprofile minimal. A heavy user-level .Rprofile makes your sessions non-reproducible.
5.15 Exercises
From a fresh user account, install R, Quarto, and Git, and render this book’s index chapter. Document every manual step you took.
Set up a dotfiles repository. Include your editor config, shell config, and Git config. Clone it on a second machine and verify the configs apply.
For a completed analysis of your own, identify three hardcoded paths or machine-specific assumptions and refactor them away.
Compare your .Rprofile to the recommendations in this chapter. List anything that should be moved to project-level config or removed entirely.
Install rig (macOS) or use the CRAN apt repository (Linux) to install R 4.3 and R 4.4 side by side. Switch between them; confirm packages install to different libraries.
5.16 Further reading
Wickham’s RStudio cheatsheets at rstudio.com/resources/cheatsheets, print them.
(Bryan, 2019), for the R-specific half of the Git setup.
(Wickham, 2023), the tidyverse style guide, worth configuring your editor to follow from the first project rather than the fifth.
The rig documentation at github.com/r-lib/rig.
5.17 Prerequisites answers
R stores installed packages in the directory returned by .libPaths()[1], typically ~/Library/R/... on macOS or ~/R/x86_64-pc-linux-gnu-library/... on Linux. With renv active in a project, the project’s private library under renv/library/ takes precedence, isolating the project’s package versions from the user library and from other projects.
A dotfile is a hidden configuration file whose name begins with a period (e.g., .zshrc, .gitconfig). Common biostatistician dotfiles: .Rprofile, .gitconfig, .zshrc/.bashrc, .tmux.conf, editor configs (init.vim, .vscode/settings.json). Version-controlling them in a public dotfiles repository is the modern standard.
RStudio provides an integrated IDE: editor, console, plots, help, and Git panes in one window, with R-specific conveniences. A terminal + Neovim + tmux workflow gives more flexibility (remote editing over SSH, editing non-R languages, scripting the environment) at the cost of a steeper setup curve and less R-specific polish. RStudio is optimal for project-focused interactive work; a terminal workflow is optimal for server-based, multi-language, or script-heavy work.