Mike this is a great question! We are working on packrat 2.0 which will be available in the coming months, as well as website to go along with it that addresses these questions.
You're right, you have to manage the libraries in addition to the repositories. There are a few ways to do this:
- One option is to use packrat (or the future packrat 2.0 project). This puts the management onus on users, and relies on project-specific libraries. You can also achieve this goal without packrat:
- Create a .Rprofile in the project directory
- Have the .Rprofile contain two commands, one to set the project-specific repo and a second to set the project-specific library (using
options('repos')and.libPathsrespectively)
- Another common option for larger organizations is to tie the system library for a specific version of R to a frozen or validated repo in Package Manager. This ensures every user on that version of R has a "shared baseline". Admins can associate different R installations (and system libraries) with different repos using
Rprofile.site, and then users would "context switch" by picking from the R installations available.
We've also seen organizations mix these two models - new users rely on the shared baseline while advanced users manage project-specific libraries. This chart demonstrates how these strategies compare and who is responsible:
https://colorado.rstudio.com/rsc/content/2154/viewer-rpubs-175c36566f2b8.html
We're laying quite a bit of groundwork this spring to make these use cases even easier - stay tuned.