Using renv as a source of truth for the R version when running a project?

[m--]

In Publisher currently, we do not have a obvious single source of truth for the R version to use when publishing a project to Connect. We'd like to lean on renv to specify this for us, so that we can pull this information from a single, documented place.

Currently, renv.lock has the R version used when the snapshot was generated. Do we want to declare that this is the source of truth for the version of R to be used when running the project, irrespective of whether it is running locally or on Connect? If not, should there be a field that makes this declaration?

[kevinushey]

IIUC, this issue is mostly tracking work external to renv; is that correct? Or are there changes that we might want to make in renv to help with that?

[jonkeane]

IIUC, this issue is mostly tracking work external to renv; is that correct? Or are there changes that we might want to make in renv to help with that?

Being external to renv is a little bit ambiguous in this case. We are hoping to use renv / the renv.lock file as the source of truth for a project's R environment needs (both for dependencies as well as for the R version that's being used). We know that the R version in renv isn't currently used / helps with installing or managing versions of R and is more of a documentation of what version was used when the file was created.

What we are hoping for is a way to communicate in the renv.lock a description of what version(s) are compatible with a project. This would allow us to rely on that field (say on Connect) when restoring the project elsewhere. One option could be that we use the current R Version field as-is and describe that as a constraint (renv already warns if there's a mismatch, though if it were a real constraint it might need a stronger warning or actually stop from working). But that seemed off to us (though we totally might be wrong about that, and maybe that field is intended to be a constraint?).

So maybe another field that is something like R RequiredVersion or TargetVersion or ProductionVersion (naming is hard, not set on any of these!) that describes a specific version (or range? Or list of versions?) that a project works with. That way the intent of that field is clear going forward: this is a constraint of the project rather than a fact of what version wrote the lockfile.

[hadley]

IMO you'd probably want to only match the major and minor version components so that R 4.2.1 locally would run on (e.g.) R 4.2.3 on connect.