IRC channel logs
2020-12-03.log
back to list of logs
<civodul>very RStudio-centered, but with good ideas it seems <civodul>apparently renv is what they use to reproduce the software environment, with a fallback to Docker <PurpleSym>civodul: I wasn’t impressed by the paper and even less the code to be honest. I’m not sure what the problem is they’re trying to solve. Right now it looks like a collection of personal tools/shortcuts for existing functionality. <PurpleSym>And the focus on R/renv ignores everything outside of the R universe (LaTeX/git). <civodul>PurpleSym: well, they say "use Docker" if you use non-R software <civodul>as if you could use exclusively R software <civodul>i guess the main contribution is a ready-to-use workflow <civodul>we just keep saying that users *can* achieve ultimate reproducibility with Guix, but we don't really say how <PurpleSym>Isn’t `guix time-machine -C channels.scm -- environment -m manifest.scm` enough, civodul? (Assuming channels.scm pins to specific commits.) <civodul>for the 10-year challenge, i had to write procedure to build PDF from LaTeX source, to build PDFs of my plots, etc. <civodul>we'd need to provide such procedures for R users, and to document a step-by-step workflow <rekado>exclusively R is sometimes not exclusively R. There are quite a few popular packages that provide “bindings” to native code (it’s often just a bundled library, not true bindings). <rekado>there’s also R itself and the BLAS library it is configured to use. <rekado>Renv is nice, but as with packrat the vision is too small. <rekado>I’ve been a little disappointed with my colleagues as I was watching their communication during my absence. <rekado>Guix has not really made it into their day to day workflows, and the temptation to drop it is big. <rekado>because a sysadmin didn’t know that the rstudio-server package in the guix-bimsb channel is absolutely fine to use they installed the RStudio Docker blob instead. <rekado>but then people couldn’t their Guix R. <rekado>so they used the system R and used the R-native way to install packages <rekado>oh, but many Bioconductor packages need some newer GCC <rekado>and some others need extra libraries <rekado>and so I watched as more and more “system” packages were installed to make it possible to install packages … that I made available in Guix months ago. <rekado>reducing this temptation is the motivation behind patching RStudio to make it more useful when it’s used from Guix. <rekado>(I wonder if this is my personal RMS Lisp Machine story) <civodul>it probably tells something about Guix too no? <civodul>maybe it feels too complicated to use for them, or too slow, or too unreliable? <rekado>unforgiving / inflexible, perhaps? <rekado>I think the biggest obstacle is that one cannot mix system and Guix packages <civodul>which isn't a problem if the packages are available tho? <rekado>right, it’s not generally a problem <rekado>but a lot of R packages are experimental <civodul>it's also a tradeoff: if it's unforgiving but its advantages outweigh that, that's ok <rekado>they are installed directly from Github via devtools, for example <rekado>here in the lab people read about something new on arxiv and try it out right away <rekado>it’s an R package that extends the R-native installation methods to directly install via a Github URL <civodul>if they could import on the fly, that could help <rekado>there’s another little wrinkle to this <rekado>devtools is used from within an R session <rekado>just like the R-native way of installing packages <rekado>you don’t generally exit your session, install a package, then start a new session with those packages available <civodul>intercept getaddrinfo calls and check if it's for github.com? :-) <rekado>provide an R procedure that overwrites or extends the native way to install packages, but it uses Guix instead. <civodul>so one could load "rguix" and it would magically make things work via guix for devtools & co.? <rekado>and we can arrange for this to be available in the Guix-installed R