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

[Thomas Petzoldt]

On 09.08.2023 at 19:18 Dirk Eddelbuettel wrote:
> 
> 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")`.

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 :)

> 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

Agreed. I'll keep my eyes open.

Many thanks, r2u and .libPaths -- should be perfect for me.

Thomas