IRC channel logs

2020-12-03.log

back to list of logs

<PurpleSym>Workflow for Open Reproducible Code in Science (WORCS): https://psyarxiv.com/k4wde/
<civodul>hi!
<civodul>PurpleSym: this looks interesting
<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
<civodul>i wonder if we could implemented the workflow as Guile/Guix modules, in the spirit of what i wrote in https://doi.org/10.5281/zenodo.3886739
<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 don't have that
<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>PurpleSym: it is!
<civodul>but that's not "a workflow"
<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.
*civodul nods
<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>Latest incident was RStudio.
<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>not great.
<rekado>reducing this temptation is the motivation behind patching RStudio to make it more useful when it’s used from Guix.
<rekado>
<rekado>(I wonder if this is my personal RMS Lisp Machine story)
<civodul>heh :-)
<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?
<civodul>or too "different"?
<rekado>unforgiving / inflexible, perhaps?
<rekado>I think the biggest obstacle is that one cannot mix system and Guix packages
<rekado>you cannot just cheat
<civodul>right
<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
<civodul>but apparently it's not
<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
<civodul>"devtools"?
<rekado>it’s an R package that extends the R-native installation methods to directly install via a Github URL
<civodul>ah ok
<civodul>if they could import on the fly, that could help
<rekado>exactly
<rekado>there’s another little wrinkle to this
<civodul>interesting
<rekado>devtools is used from within an R session
<rekado>just like the R-native way of installing packages
<civodul>oh right
<civodul>yeah, so we can't really compete
<rekado>you don’t generally exit your session, install a package, then start a new session with those packages available
<rekado>well… but we can!
<rekado>we can augment R
<civodul>ah sure, add a devtools backend?
<rekado>simpler
<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.
<rekado>just a bit of R glue
<civodul>oh nice
<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
<civodul>neat
<rekado>yes, that’s the thought
<civodul>good
*civodul -> zZz
<civodul>night!
<rekado>good night!