Thomas,
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")`.
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".
On 9 August 2023 at 18:58, Thomas Petzoldt wrote:
| Am 09.08.2023 um 18:17 schrieb Dirk Eddelbuettel:
| > Yes. If and when that happens, it is a bug!
|
| Not necessarily. Breaking code can also be due to an incompatible
| feature update. We know that R has both, conservative and less
| conservative universes of packages ;-) Security is another issue.
I am talking more narrowly about the failure to install a package, or getting
the wrong package, or ... as a bug in the r2u setup and provision. Those bugs
we should squash. All others continues to exist, and we fight them in
different venues.
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
