Is it possible to use a single renv across multiple projects?

[slodge]

We're beginning to see a common pattern evolve where we write packages, jobs and reports together.

For example, we might be working on a new DeepThought package. Alongside that we might have some DeepThought processing jobs and some DeepThought dashboards. So we might have a group of RProjects that look like:

/ DeepThought
  / DeepThought.Package
    - DeepThought.Package.Rproj
    - DESCRIPTION
    / R
       - *.R files
  / DeepThought.Processing
    - DeepThought.Processing.RProj
    - Process1.R
    - Process2.R
    - .... other R files
  / DeepThought.Shiny
    - DeepThought.Shiny.RProj
    - App.R
    / R
        - ... other R files

Ideally I'd like all of the projects in DeepThought to share the same Renv environment - e.g. to share the same tidyverse version.

Is there a way to do that? e.g. can we chain .RProfile files together somehow to share a single renv environment?

[nirgrahamuk]

you could write your own functionality to parse the JSON of the various renv.lock files,
find commonalities, differences, amend them and write them out again.

[slodge]

I guess another way of asking this is - how would renv be applied to a case study like https://github.com/sol-eng/bike_predict ?

That case study has nested RProj files - with the package specific project inside the outer project - can I apply renv to the outer project and have the inner package project pick that up automatically?

[kevinushey]

You could have all of the sub-projects share the same library + lockfile by using a custom loader in each sub-project's .Rprofile; e.g. with something like:

setwd("path/to/project/root")
source(".Rprofile")

You might also be able to just use renv::load("path/to/project") in each case to explicitly load a particular project.

[slodge]

Thanks

In the https://github.com/sol-eng/bike_predict particular example is the subproject for the pkg necessary? Is it recommended as good practice?

I'm wondering whether we should just go with a single project at the top level - the only thing we want RCMD to build is the package folder and it looks like the parent project can give us that using the lines:

BuildType: Package
PackageUseDevtools: Yes
PackagePath: pkg
PackageInstallArgs: --no-multiarch --with-keep.source

[kevinushey]

I would say that most typically, the package itself is the top-level project item (the package is the project). However, in larger projects where the R package might just be one component of the project, then this sub-directory approach may be more appropriate.

Ultimately, I believe it comes down to whatever feels most natural for you.