FR: make recovering from OS upgrades less painful by identifying when library was built under a different OS
kmasiello opened this issue · comments
Description
In the case where a team is undergoing an OS upgrade, the project-level library established via renv must be rebuilt. Currently, there is not an easy way for users to know that their library was built under a different OS.
To recover from an OS upgrade, a user will need to rebuild the cache for every renv project using a script similar to:
# Delete the existing libraries
unlink("renv/library", recursive=TRUE)
# Restart R session
.rs.restartR()
# Re-install libraries
renv::restore(rebuild = TRUE)
This is not well-documented, requires a user to perform this individually for every project, and its not possible to inspect a renv project to determine if it has been rebuilt to the new OS or not.
Suggested Approach
Similar to how renv::status() will notify if a lockfile was built per a different version of R, renv::status() should identify if the library cache was built against a different OS.
Impact
This work becomes very important as RHEL7 reaches EOL. We are coaching a large number of customers through OS upgrades and the renv rebuild actions put a significant burden on users.
For what it's worth, it's possible to tell renv to include the operating system's name in the library paths by setting the environment variable:
RENV_PATHS_PREFIX_AUTO = TRUE
and this would normally be set in the R installation's etc/Renviron.site or something similar. Then, library paths would include information about the OS; for example:
> Sys.setenv(RENV_PATHS_PREFIX_AUTO = TRUE)
> renv::paths$library()
[1] "/home/kevin/renv/library/linux-ubuntu-jammy/R-4.2/aarch64-unknown-linux-gnu"
I'd like to eventually turn this on by default, but since this would be a breaking change (it would also change the computed library path for existing projects) I've been hesitant to.
Reference: https://rstudio.github.io/renv/reference/paths.html#sharing-state-across-operating-systems
Yeah, I actually tried to do some experimentation with that environment variable but fumbled around a lot. It's user error likely, but also frustrating that it is so hard to configure correctly. Also, am I right that this environment variable would help for future projects, but won't do anything to help retroactively address projects created prior to setting the environment variable?
Also, am I right that this environment variable would help for future projects, but won't do anything to help retroactively address projects created prior to setting the environment variable?
This would affect existing projects as well. The big problem is that existing projects would have their library paths changed, and so currently-functional projects would be non-functional until the project library was migrated from the old to the new location, or until the user ran renv::restore() or similar.
Similar to how renv::status() will notify if a lockfile was built per a different version of R, renv::status() should identify if the library cache was built against a different OS.
This is, unfortunately, challenging to detect in general. We might be able to infer this in some cases for some packages, but I don't think we could do this reliably in all cases. This is part of the reason why I eventually want to include the OS in the library paths (as RENV_PATHS_PREFIX_AUTO = TRUE would).
Would it make sense to do the OS update and the switch to RENV_PATHS_PREFIX_AUTO together? (If we were able to convince ourselves that the environment variable were behaving as it should be)
I'm warm to that idea. However, it will be a moot point if the repo url in the lock file is still pointing to the old os binary url. I fear we're getting to too many moving parts.