eddelbuettel / r2u

CRAN as Ubuntu Binaries

Home Page:https://eddelbuettel.github.io/r2u

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Source package versions installed within `{renv}`

rpodcast opened this issue · comments

I'm very excited for r2u as I've been running R on Ubuntu since the days of 8.04 Hardy Haron!

I leverage {renv} in almost all of my R projects. After I configured r2u successfully on my Ubuntu 20.04 laptop (and confirmed the binary packages installed without issue), I noticed that after bootstrapping an {renv} project that source versions of packages were installed after running renv::install("name_of_package") , which I believe is supposed to act as a shim to the default install.packages(). If this issue is more related to bspm, I'd be glad to move this over.

That sounds like an renv issue to me. Also note that the installation within RStudio's GUI 'does its own thing' and bypasses install.packages() and update.packages() meaning it cannot work with bspm. CCing @Enchufa2 here but I fear you may just be out of luck (and I simply will have to document this, as I should document the known bspm issue with the RStudio GUI).

In short, install.packages() and update.packages() are your friends. For everything else you are on your own.

Cool about your long Ubuntu story. Same here. I don't actually have notes when I started / switched from Debian testing for some / most machines but I think it was also a year in and around then.

AFAIK, renv nowadays acts as a shim to pak, and pak does its own thing, it doesn't rely on install.packages() at all. This is unavoidable, because install.packages() just works with the current version of packages, and renv and pak aim at installing any archived version. So, in principle, renv/pak cannot work with r2u by design.

The issue with RStudio's GUI is not that it bypasses anything. The problem is that it calls install.packages() in a vanilla R session, which bypasses any bspm configuration (see cran4linux/bspm#39 and the RStudio issue referenced there).

Thanks for additional colour. I will leave this open til I add a line or two to the package documentation that underlies r2u.

And just to be plain and repeat/reword the correct by design statement: r2u and its 19k binaries are of course entirely functional. Opting into a installation-support functionality that does not use them is of course entirely possible, but not exactly our concern here. Another case of cake and eating possibly separated. Choices are good, tools have their places and users can (and will and should) merrily self-select into what they prefer.

I've opened cran4linux/bspm#41. If we implement this mechanism, then we could go bother the renv/pak maintainers and ask them to talk to bspm, if present, so that packages are installed via bspm if the user requests a current version (in general, a version that matches what's in the system repos).

And to be clear, when I said that "renv/pak cannot work with r2u by design," I meant by design... of renv/pak, of course.

Hello,
I am also interested by the feature of having renv and r2u working together, especially in docker.
I tested eddelbuettel/r2u:22.04 and it is absolutely brilliant, thanks @eddelbuettel ! Works as expected, fantastic setup.
I tried to use renv inside a container and this install works as it should

[...]
The following package(s) will be updated in the lockfile:

# RSPM ===============================
- renv   [* -> 0.15.5]

* Lockfile written to '/test/renv.lock'.
* Project '/test' loaded. [renv 0.15.5]
* renv activated -- please restart the R session.

the renv.lock is using RSPM correctly:

  "Packages": {
    "renv": {
      "Package": "renv",
      "Version": "0.15.5",
      "Source": "Repository",
      "Repository": "RSPM",
      "Hash": "6a38294e7d12f5d8e656b08c5bd8ae34",
      "Requirements": []
    }
  }

however, after restarting the session, any call to renv::install() or install.package() is bypassing RSPM.
Any idea how I should do it? I am not in RStudio GUI here and renv is able to register RSPM correctly before it gets activated.
Many thanks again for those great efforts.

As we stated above, what renv does is outside our control. You would have to convince its author to support bspm by relying on the standard installation routines,

As renv does its own thing, it does not take advantge of the binaries used by bspm and hence r2u.

Thanks Dirk. I have raised some concerns in August 2020 (concerning BSPM and renv, see rstudio/renv#519) but apparently I was not convincing enough. In your last sentence, I guess you wanted to write "it does not take advantage"

I am going to close this as it is a design choice at renv and not something we can do anything about, sadly.