On 9 August 2023 at 21:59, Thomas Petzoldt wrote: | On 09.08.2023 at 19:18 Dirk Eddelbuettel wrote: | > There is a fifth option I just realized. | > | > I use a variant of that to keep for example an old version of roxygen2 I | > prefer available. Recall that R packages are generally relocatable. So | > install the 58 you need, then do, say `mkdir /opt/shiny-r-lib` and copy them | > in there. Setup your shiny deployment with whatever R_LIBS_USER or | > R_LIBS_SITE works for, or simply add `.libPaths("/opt/shiny-r-lib")`. | | Awesome! I remember that I saw this idea somewhere at a webpage, but | part of the explanation confused me and I forgot about it. Thanks for | the reminder -- and your trustworthy second opinion. | | > Now those packages will be found first, used by Shiny and cannot be touched | > by install.packages (be it with `apt` via `r2u` or not). Easy peasy "poor | > man's virtual environemnt". | | ... and it allows multiple package sets in parallel for testing, ... or | different .libPaths() for specific apps. The typical library is small | (approx. 250 pkgs), so that space is no problem and a full copy took | just a second :)
Exactly. The key is keep the default R_LIBS_* and .libPaths() for the normal system and update, and aside versions for custom uses. After all many of us have done just that with r-devel installed alongside r-release too. So if only your shiny app and its setup know a separate library path, nobody else can mess with it. In a way a more primitive and less solid form than shielding via Docker instance, but likely "good enough". | Many thanks, r2u and .libPaths -- should be perfect for me. Perfect. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian