Open klmr opened 3 months ago
This all seems quite unexpected -- renv::restore()
should definitely at least be printing a summary of the changes it wants to make, and give you an opportunity to respond.
If you run with the R profiler enabled, e.g. using:
Rprof("renv.Rprof")
renv::restore(clean = TRUE)
Rprof(NULL)
summaryRprof("renv.Rprof")
does the output give you any hints as to what renv
is busy doing? (Alternatively, are you able to debug(renv::restore)
and step through to see how far you get before the function exits?)
Hm. I now get some output from renv::restore(clean = TRUE)
, even though nothing in this repository was changed:
✔ Loading metadata database ... done
ℹ No downloads are needed
✔ 1 pkg: [2.7s]
However, the behaviour is otherwise the same.
Here’s the Rprof output:
summaryRprof("renv.rprof")
Based on that output, I suspect the issue here lies with how pak
is being invoked by renv
... do you have better luck with options(renv.config.pak.enabled = FALSE)
?
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 renv
is invoking pak
, and should be resolved in the development version of renv
.
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 renv::status()
:
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 renv::status()
it looks like renv::restore()
didn’t actually do… anything?!
I tried the same using the dev version of ‘renv’, with the same result.
This sounds similar to a recent issue where renv
's dependency repair seemed to malfunction when the restore would act upon a library path that already contained differing versions of packages...
For diagnostics, does the issue still occur if you restore into a separate library path, e.g. something like:
renv::restore(library = "/tmp/renv-library")
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 renv
that needs to be fixed.)
Could you also share a couple of files?
renv::restore()
;renv::snapshot(lockfile = "renv-current.lock")
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 renv::status()
still showed the mismatching versions — identical output as above. But then I remembered that .libPaths()
wasn’t adjusted, and once I added the temporary library path to .libPaths()
, renv::status()
showed me a consistent state.
Maybe that’s a hint at what’s going wrong? I.e. that renv::restore()
might somehow be using an incorrect library path? (I did check the library
by stepping through renv::restore
, and it corresponds to the value of .libPaths()[1]
, as expected.)
(At this point I should also note that renv::status()
is in fact showing the correct status: I have manually verified that the package versions in the library and in the lockfile were as shown; so the error isn’t in renv::status()
.)
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).
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:
Perhaps renv_dependencies_discover_description()
is returning the wrong value here for some reason; e.g. using the version of a package currently-loaded or available in the library paths, as opposed to the version that was just downloaded?
A couple other options you could try setting, before attempting restore:
# disable internal caching / memoization of computed values
options(renv.dynamic.enabled = FALSE)
# disable caching of values computed from files on disk
options(renv.config.filebacked.cache = FALSE)
If either of these help, it could help narrow down the issue as well.
I'm using version 1.0.8 and with pak
I also get incorrect versions installed. All the versions in the library are newer which leads me to believe pack simply grabs whatever is the latest version at the moment.
I tried it now with pak disable and with the two options you provided and the result is the same.
# CRAN -----------------------------------------------------------------------
- broom [1.0.5 != 1.0.6]
- colorspace [2.1-0 != 2.1-1]
- data.table [1.15.4 != 1.16.0]
- DBI [1.2.2 != 1.2.3]
- distributional [0.4.0 != 0.5.0]
- fabletools [0.4.2 != 0.5.0]
- feasts [0.3.2 != 0.4.0]
- filelock [r-lib/filelock != 1.0.3]
- ggnewscale [0.4.10 != 0.5.0]
- jsonlite [1.8.8 != 1.8.9]
- odbc [1.4.2 != 1.5.0]
- openssl [2.1.2 != 2.2.2]
- rlang [1.1.3 != 1.1.4]
- tsibble [1.1.4 != 1.1.5]
- urca [1.3-3 != 1.3-4]
- yaml [2.3.8 != 2.3.10]
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.
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
``` > renv::restore(clean = TRUE) > renv::status() The following package(s) are in an inconsistent state: package installed recorded used httr y y n The following package(s) are out of sync [lockfile != library]: # RSPM --------------------------------------------------------------------- -- - askpass [repo: CRAN != RSPM; ver: 1.1 != 1.2.0] - brio [repo: CRAN != RSPM; ver: 1.1.3 != 1.1.5] - bslib [repo: CRAN != RSPM; ver: 0.5.1 != 0.7.0] - cachem [repo: CRAN != RSPM; ver: 1.0.8 != 1.1.0] - callr [repo: CRAN != RSPM; ver: 3.7.3 != 3.7.6] - cli [repo: CRAN != RSPM; ver: 3.6.1 != 3.6.3] - cpp11 [repo: CRAN != RSPM; ver: 0.4.6 != 0.4.7] - curl [repo: CRAN != RSPM; ver: 5.0.2 != 5.2.1] - desc [repo: CRAN != RSPM; ver: 1.4.2 != 1.4.3] - digest [repo: CRAN != RSPM; ver: 0.6.33 != 0.6.36] - downlit [repo: CRAN != RSPM; ver: 0.4.3 != 0.4.4] - evaluate [repo: CRAN != RSPM; ver: 0.22 != 0.24.0] - fansi [repo: CRAN != RSPM; ver: 1.0.4 != 1.0.6] - fastmap [repo: CRAN != RSPM; ver: 1.1.1 != 1.2.0] - fs [repo: CRAN != RSPM; ver: 1.6.3 != 1.6.4] - glue [repo: CRAN != RSPM; ver: 1.6.2 != 1.7.0] - highr [repo: CRAN != RSPM; ver: 0.10 != 0.11] - htmltools [repo: CRAN != RSPM; ver: 0.5.6 != 0.5.8.1] - httr2 [repo: CRAN != RSPM; ver: 0.2.3 != 1.0.2] - jsonlite [repo: CRAN != RSPM; ver: 1.8.7 != 1.8.8] - knitr [repo: CRAN != RSPM; ver: 1.44 != 1.48] - lifecycle [repo: CRAN != RSPM; ver: 1.0.3 != 1.0.4] - openssl [repo: CRAN != RSPM; ver: 2.0.6 != 2.2.0] - pkgdown [repo: CRAN != RSPM; ver: 2.0.7 != 2.1.0] - processx [repo: CRAN != RSPM; ver: 3.8.2 != 3.8.4] - ps [repo: CRAN != RSPM; ver: 1.7.5 != 1.7.7] - ragg [repo: CRAN != RSPM; ver: 1.2.5 != 1.3.2] - rmarkdown [repo: CRAN != RSPM; ver: 2.25 != 2.27] - sass [repo: CRAN != RSPM; ver: 0.4.7 != 0.4.9] - systemfonts [repo: CRAN != RSPM; ver: 1.0.5 != 1.1.0] - textshaping [repo: CRAN != RSPM; ver: 0.3.7 != 0.4.0] - tinytex [repo: CRAN != RSPM; ver: 0.47 != 0.52] - utf8 [repo: CRAN != RSPM; ver: 1.2.3 != 1.2.4] - withr [repo: CRAN != RSPM; ver: 2.5.0 != 3.0.0] - xfun [repo: CRAN != RSPM; ver: 0.40 != 0.46] - yaml [repo: CRAN != RSPM; ver: 2.3.7 != 2.3.10] See ?renv::status() for advice on resolving these issues. ```
``` R version 4.3.1 (2023-06-16) Platform: aarch64-apple-darwin20 (64-bit) Running under: macOS Sonoma 14.3.1 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.11.0 locale: [1] en_GB.UTF-8/UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8 time zone: Europe/Zurich tzcode source: internal attached base packages: [1] stats graphics grDevices datasets utils methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 tools_4.3.1 yaml_2.3.10 renv_1.0.7 pak_0.7.2 ```sessionInfo()
output