renv::restore() does not restore lockfile package versions #1953
Comments
|
This all seems quite unexpected -- If you run with the R profiler enabled, e.g. using: does the output give you any hints as to what |
|
Hm. I now get some output from However, the behaviour is otherwise the same. Here’s the Rprof output:
|
|
Based on that output, I suspect the issue here lies with how It's also possible this is the same as https://github.com/rstudio/renv/blob/main/NEWS.md?plain=1#L47-L49 -- if that's the case, then this is a bug with how |
|
Okay, disabling ‘pak’ did change the behaviour, it asks to restore a bunch of packages, and does so after prompting. However, afterwards the library is still not synchronised, as shown by I guess the reason for this is explained by the messages during installation (“Installation of 'PKG VERSION' was requested, but the following constraints are not met: […] renv will try to install 'PKG OTHE_VERSION' instead.”) but it’s not clear why this happens, since the previously snapshotted state of the library was internally consistent. |
|
Hm. Actually from the output of I tried the same using the dev version of ‘renv’, with the same result. |
|
This sounds similar to a recent issue where For diagnostics, does the issue still occur if you restore into a separate library path, e.g. something like: Or alternatively, attempt the restore only after cleaning up the library paths? (This might be suitable as a workaround, but even so it seems like there's definitely a bug in |
|
Could you also share a couple of files?
This should let me try and reproduce from a similar state as from what you're working with. |
|
Okay, I tried restoring into a separate library path, and I originally got the same behaviour as when disabling ‘pak’ above: it restores everything, but afterwards Maybe that’s a hint at what’s going wrong? I.e. that (At this point I should also note that I’ve attached the requested files. Unfortunately the project is relatively complex. I can try to simplify it if absolutely necessary. I’ll also list my ‘renv’ config below. I’ve censored some company specifics. All censored CRAN-like repo URIs lead to valid PPM instances (I tested them just now to be sure). ‘renv’ configAnd the paths: |
|
Darn -- even trying to replicate a restore using the same set of packages as in your case, I'm not able to reproduce. 😞 Based on the error, my suspicion is that something is going wrong when computing and adding the requirements for each package during restore here: Lines 1052 to 1064 in 6d80457 Perhaps A couple other options you could try setting, before attempting restore: If either of these help, it could help narrow down the issue as well. |
|
I'm using version 1.0.8 and with I tried it now with pak disable and with the two options you provided and the result is the same. I guess the theory that it is trying to bump versions to get a resolvable set might be correct. But I don't know which package might be causing the problem and also... that should rather produce an error. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Inside an renv project I installed a new version of a package (and numerous updated dependency versions) via
renv::install(the_pkg). Unfortunately this caused some issues, so now I want to revert to a known-good version.So I ran
renv::restore(clean = TRUE). The function runs for a while before finishing without creating any output. Unfortunately apparently nothing was done:renv::status()shows me that the lockfile versions of the packages were not restored (see output below). Runningrenv::restore()repeatedly (with or withoutclean = TRUE) and restarting the R session does not change this situation.Am I misunderstanding how
renv::restore()is supposed to behave in this situation?R console output
sessionInfo()outputThe text was updated successfully, but these errors were encountered: