1

I currently experiment with renv to ensure that all of my collegues use the same version of packages during development. However, there is one thing I don't know how to achiev to far.

Let's say there is a package A that requires a specific version of an exampleLibrary, let's say 1.0.0. This leads to the fact that the renv.lock of this package has some entry like this:

"exampleLibrary": {
      "Package": "exampleLibrary",
      "Version": "1.0.0",
      "Source": "Repository",
      "Repository": "GITLAB",
      "Hash": "c0e49a9760983e81e55cdd9be92e7182",
      "Requirements": []
}

Now, after some time, someone develops another package B, and want to use some utility from package A. He calls renv::install("package A"). This leads to a similar entry of the above snippet within the renv.lock of package B.

However, what if the following happens: after some time you forget that package A depends on exampleLibrary 1.0.0 and you run renv::install("exampleLibrary@2.0.0") because you want to upgrade exampleLibrary. This replaces the entry in renv.lock without any warnings or errors. This may lead to big trouble when package A does not work with exampleLibrary@2.0.0.

I would have expected that renv encodes the dependencies of packages something like:

"package A": {
      "Package": "package A",
      "Version": "1.0.0",
      "Source": "Repository",
      "Repository": "GITLAB",
      "Hash": "c0e49a9760983e81e55cdd9be92e7182",
      "Requirements": [exampleLibrary (==1.0.0)]
}

Another example of this scenario is that you install two packages that have the same dependency but with other versions. The version of the latter installed packages is finally taken without any warnings.

Is there any way to prevent this?

Ai4l2s
  • 525
  • 2
  • 9

1 Answers1

0

Sorry, but what you describe isn't possible with renv. The model used by renv is that renv::snapshot() saves the state of your R library -- no more, and no less. The onus is on the user to verify that the library itself is in a valid state before calling renv::snapshot().

However, what if the following happens: after some time you forget that package A depends on exampleLibrary 1.0.0 and you run renv::install("exampleLibrary@2.0.0") because you want to upgrade exampleLibrary. This replaces the entry in renv.lock without any warnings or errors. This may lead to big trouble when package A does not work with exampleLibrary@2.0.0.

renv::install() will only update renv.lock if you've enabled automatic snapshots -- see https://rstudio.github.io/renv/reference/config.html#renv-config-auto-snapshot for details. By default this is off, so you would need to explicitly call renv::snapshot() after installing or updating some packages to have those recorded in the lockfile.

Another example of this scenario is that you install two packages that have the same dependency but with other versions. The version of the latter installed packages is finally taken without any warnings.

Note that R generally doesn't support having multiple versions of the same package installed or loaded at the same time -- you have to pick a specific version. This is part of the reason why renv doesn't try to encode specific package versions as requirements for packages, as one would quickly discover unresolvable conflicts.

Kevin Ushey
  • 20,530
  • 5
  • 56
  • 88