[R-sig-Debian] pinning of binary r-cran-* packages from c2d4u / r2u on Ubuntu 22.04

[Dirk Eddelbuettel]

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 | edd using debian.org