Allow renv::restore to help updating packages when restore fails

[torbjorn]

After updating to R 4.4 I just spent 20 minutes repeating the following procedure to restore an old project:

• renv::restore()
• renv::update("packagethatcausedproblems")
• renv::record("packagethatcausedproblems")
• rinse and repeat

Could we have restore(and_try_updating_to_make_it_work=TRUE) handle this itself? (With a better argument name obviously)

There is no need for a human to be at the helm to do the above routine repetatively for a period of time. Of course there are perfectly valid reasons why more or less blindly updating arbitrary packages isn't a good idea, but I imagine, for probably a large majority of projects, package versions that are no longer installable can be safely updated as the prefered solution instead of troubleshooting installation of old versions.

Halfway through I tried renv::update() to just update all packages, (and risking rebuilding packages not in cache), but this didnt fix things, still had to go back to update individual packages and repeat. This is also not an ideal solution as you now update everything and not just the ones that are causing a problem.

[kevinushey]

Sounds like you want renv::install() instead of renv::restore(), if the specific package versions in your lockfile aren't actually required?

[slodge]

I'm not entirely sure if this is the same thing that @torbjorn is commenting on, but I can confirm that upgrading 30 or so renv controlled repos from r4.1 to r4.2, and then a year later to r4.3 did require a lot of manual effort. This was mainly down to changes in
R build requirements which meant that old versions of packages wouldn't install - so we had to upgrade them.

Ideally we'd have keep the same package versions when upgrading r version - we only find out which packages have to be upgraded by renv restore trial and error..

[torbjorn]

At this point, wiht 10's of projects at hand, I'll likely write a try-catch function to do the above.

[torbjorn]

I'm sourcing a scripts that does this for the moment to handle this:

while(TRUE) {

    t <- try(renv::restore(prompt=FALSE, clean=FALSE))

    if(!inherits(t, "try-error")) {
        break
    }

    txt <- as.character(t)
    r <- gregexec("install of package '(.*?)' failed", txt, perl=TRUE)

    if( any(r[[1]] == -1) ) {
        break
    }

    pkg <- regmatches(txt,r)[[1]][2,1]

    renv::update(prompt=FALSE, packages=pkg)
    renv::record(pkg)

}

[wcurrangroome]

echoing that this has been a problem with prior R updates for me as well, and I've run into exactly the same challenges as @torbjorn describes with the change to 4.4

[kevinushey]

I might be misunderstanding something, but -- why do you want to update R, without also updating the packages used by your project?

Quite often, older versions of R packages will fail to build / compile against newer versions of R. Or, other runtime incompatibilities can arise when using older versions of R packages with newer versions of R. These are, more-or-less, outside of renv's control.

Since CRAN uses a rolling release model, your best shot at a good / compatible state is to take the latest-available packages at some particular point in time. Occasionally, you may need to break these rules, but I think that's the baseline that should normally be used.

Mixing different versions of packages from different release times without careful thought is dangerous.