The following seemed to be simplest for me on macos.
brew install --cask r
brew install r without the
cask part leads to some compilation issues for package dependencies
For ubuntu, it seems less troublesome to use the OS packages.
deb https://cloud.r-project.org/bin/linux/ubuntu focal-cran40/ to the apt source list
sudo vim /etc/apt/sources.d/r.list.
Now, secure it then install things.
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9 sudo apt-get update sudo apt-get install r-base r-base-dev
In either case, you can also install it via the package manager
conda but this is not recommended because nothing at all seems to compile then.
Installing R packages
Classic style, you install a bunch of R packages in a central location and keep them up to date.
Recommended: use some dependency management system such as
renv, see below.
Smoother experience for macos
https://macos.rbind.io(Github repo) provides some binary R packages for the Homebrew (cask) version of base R that are currently missing on CRAN, in a similar spirit as the “CRAN extras” repository for Windows:
https://www.stats.ox.ac.uk/pub/RWin/. If you are using the Homebrew version of R on the latest version of macOS, you may set the
reposoption in R first:
Choosing package location
Depending on when and how you install(ed) R your packages can end up in all manner of silly and inconsistent places.
The best plan
is to specify somewhere consistent by setting
R_LIBS_USER in your
For some setups the default value is
R_LIBS_USER=~/R/%p-library/%v, although not for a fresh R install on my work machine, so I would recommend setting it to something to be safe.
~/R/%p-library/%v, conservatively assumes you might share the same packages folder across multiple different platforms, which is unlikely for your own private computer, although not crazy if you are moving your use library to different architectures across upgrades.
R_LIBS_USER=~/R/%v is might sufficient for normal people.
Note that it does not work if the folder does not exist:
> dir.exists(Sys.getenv('R_LIBS_USER'))  FALSE
so in that case run this:
> dir.create(Sys.getenv('R_LIBS_USER'), recursive = TRUE) > dir.exists(Sys.getenv('R_LIBS_USER'))  TRUE
then restart R.
renv I think is the current preferred environment management system for a project which should have fixed dependencies. There is some older system called packrat which I gather we can all safely ignore as deprecated.
The general workflow when working with
[renv::init()](https://rstudio.github.io/renv/reference/init.html)to initialize a new project-local environment with a private R library,
- Work in the project as normal, installing and removing new R packages as they are needed in the project,
[renv::snapshot()](https://rstudio.github.io/renv/reference/snapshot.html)to save the state of the project library to the lockfile (called
- Continue working on your project, installing and updating R packages as needed.
[renv::snapshot()](https://rstudio.github.io/renv/reference/snapshot.html)again to save the state of your project library if your attempts to update R packages were successful, or call
[renv::restore()](https://rstudio.github.io/renv/reference/restore.html)to revert to the previous state as encoded in the lockfile if your attempts to update packages introduced some new problems.
is a kind of ultralight
renv-wrapper that allows you to test code against multiple specific packages and package versions.
A capsule is a stable project-specific R package library that you consciously choose to execute code within. Think of it as representing 'production', while your normal interactive R session represents 'development'.
You develop interactively in a dynamic package environment. You run code for real in a well-defined static capsule. Periodically you’ll want to have your development environment reflected in the capsule as new stuff is integrated.
When sharing with others, a capsule is the fallback that ensures your code can always be run, no matter what issues appear in your collaborator’s development environment.
Pro tip: If you use a dependency system such as
renv which creates an
.Rprofile file to automatically execute the initialisation scripts then you will no longer be executing your system-wide
You may need to add a line to your project-local
How do you do that? It’s not so hard, and as Hilary Parker points out, saves you time.
- Level 1, Hilary Parker, Writing an R Package from Scratch
- Level 2, Fong Chun Chan, Making Your First R Package
- Level ∞, Hadley Wickham, R packages
Those are the HOWTOs. Here are some useful tools.
easy project reload
Make a folder called MyCode with a DESCRIPTION file. Make a subfolder called R. Put R code in .R files in there. Edit, load_all("MyCode"), use the functions.
Hadley Wickham pro-style
Here’s an intro to the OO facilities of R - although I recommend going for a functional style as much as possible to avoid pain.
Hadley has written lots of useful helper tools for this process. Here are two:
pkgdown is an easy tool for documenting R packages:
pkgdown is designed to make it quick and easy to build a website for your package. You can see pkgdown in action at https://pkgdown.r-lib.org: this is the output of pkgdown applied to the latest version of pkgdown.
usethis is a workflow package: it automates repetitive tasks that arise during project setup and development, both for R packages and non-package projects.