How should RSPM work with libraries? about environments.rstudio.com HOT 2 CLOSED

One thing worth saying: renv's purpose is primarily to allow users to manage their own project-local R libraries. Do we need to think about whether renv should also allow an organization to manage R libraries that are then used by its users?

from environments.rstudio.com.

@kevinushey I've been wondering about that question as well.

For the first use case (per-project time traveling through checkpoints), you can get pretty far by using renv as it exists today; e.g.

options(repos = c(CRAN = 'https://my-pkgs.example.com/cran/123'))
renv::init()

That will reinstall everything for the project at transaction 123, even if the user had never touched renv previously.

The 2nd case is more difficult though - because the challenge goes beyond per-project library management. The most common "solution" I see implemented in the wild is for admins to install packages into the system library. Usually, they tie this to R versions; e.g. each R version gets its own system library of packages. Naive admins will update that system library over time 😱 , more cautious admins will install all the packages at once and then not touch them until the next R version comes out with a new system library. We've worked hard in RSPM to make sure curated sources behave in the middle of these 2 approaches: admins can add packages overtime to the repo, but they always get added from the same "checkpoint" unless the admin explicitly updates. However, we don't give admins an easy way to keep a system library in sync with a curated source.

I almost wonder if we could give them tooling to do that in a safer fashion... I'm not sure what that would be though. I'm not sure that would be a great use case for renv; admins might prefer an affordance in the IDE or some way to interact with Rprofile.site. If you have any ideas, I'd be all ears. Let me know if the use case isn't clear.

from environments.rstudio.com.