grantmcdermott / codespaces-r2u Goto Github PK

From @eddelbuettel's comment in #1 (comment).

Yet we also have the dual list files. Two of these are from your Dockerfile, two of them are not so we may need to have a look at the other scriptlets that run:

r$> system("ls -ltr /etc/apt/sources.list.d/")
total 16
-rw-r--r-- 1 root root 129 Aug  4 23:23 cran.list
-rw-r--r-- 1 root root 127 Aug  4 23:23 r2u.list
-rw-r--r-- 1 root root  76 Aug  4 23:24 cran-ubuntu.list
-rw-r--r-- 1 root root  65 Aug  4 23:24 cranapt.list

The great selling point of r2u is that it installs R package binaries and resolves system dependencies. Unfortunately, this doesn't appear to be working quite as expected here.

The very first time I try to install an R package (e.g., install.packages("data.table")) after instantiating a codespace, it doesn't fetch the binaries and instead installs/builds from source. Example output:

r$> install.packages("data.table")
Install system packages as root...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Reading package lists... Done    
Building dependency tree... Done 
Reading state information... Done
Fetched 0 B in 0s (0 B/s)                                                                                                                                                             
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
trying URL 'https://cloud.r-project.org/src/contrib/data.table_1.14.8.tar.gz'
Content type 'application/x-gzip' length 5338582 bytes (5.1 MB)
==================================================
downloaded 5.1 MB

* installing *source* package ‘data.table’ ...
<etc>

However.... What's even stranger is that once I q() this first R session and open a new one (e.g., by manually opening up an R terminal) then everything works as expected. Running install.packages("PKGNAME") installs the binary from the r2u mirror and resolves any system deps.

r$> install.packages("data.table")
Install system packages as root...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Reading package lists... Done    
Building dependency tree... Done 
Reading state information... Done
Get:1 https://r2u.stat.illinois.edu/ubuntu jammy/main amd64 r-cran-data.table amd64 1.14.8-1.ca2204.1 [1833 kB]                                                                       
Fetched 1833 kB in 0s (0 B/s)                                                                                                                                                         
Selecting previously unselected package r-cran-data.table.
(Reading database ... 48038 files and directories currently installed.)
Preparing to unpack .../r-cran-data.table_1.14.8-1.ca2204.1_amd64.deb ...
Unpacking r-cran-data.table (1.14.8-1.ca2204.1) ...
Setting up r-cran-data.table (1.14.8-1.ca2204.1) ...

Can we base a devcontainer on something ubuntu-latest, opening the door to r2u, and also offer GPU / CUDA support?

@eitsupi Is there an existing 'feature' to turn on or how would you suggest we go about this?

My tweet / toot / skeet storm about the r2u codespace/devcontainer worked quite well. Thank you both for all the help in making it possible with r2u.

So now that @eitsupi cleaned up and simplified and this works on top of his work already bringing bspm (thanks, @Enchufa2, all weirdnesses experienced here in prior version were local) the README.md needs two or three trenchant bullet points of why people should start here and with this.

Obviously, being able to run any CRAN package near-immediately on a cloud-hosted box is great. Maybe we can record a quick screen shot video to post your example.R in action. (Sadly, peek which I used before seems to have some sort of measles under 23.04. If needed I could try on a 22.04 machine.)

Even closed, Codespaces still accumulate costs based on the storage used until they are deleted. While this is typically pennies, it's worth warning users about this (say, if you downloaded 500gb of data...)

Now that all this works (thanks, @eitsupi) we could consider enabling an option @Enchufa2 added to bspm at my (always impatient) urging: options(bspm.version.check=FALSE) will make the 'what is available' lookup quicker by limiting it to binaries.

That means that if and mean a newer source is available, it will be ignore. It also means if installation demands can be satisfied (with r2u and jammy, essentially) they will be done a little quicker.

It's a judgement call. I know how fast it can be so it irks me (in interactive or CI use). For a more general use it can be argued that the current default is in fact good. I have no problem seeing this issue closed -- but I figured it was worth mentioning the available 'free' option we have here.

It's never super obvious (to me) how to expand on this at install time. Now that the container can simply use apt, an example on how to install a user's favorite packages at setup time (e.g., ggplot2) would be great. Maybe even using the "repo2docker" specs https://mybinder.readthedocs.io/en/latest/using/config_files.html#install-r-install-an-r-rstudio-environment