Pjotr Prins <pjotr.publi...@thebird.nl> writes: > On Sun, Jul 31, 2016 at 01:49:00PM -0400, myglc2 wrote: >> > I think what you're looking for in your hospital research lab is what >> > Pjotr describes as a certain check-out of the Guix source tree. >> >> But it is not simple to use. It is to technical an approach to appeal to >> the medical researchers I have worked with. > > If it is that bad :) You have a choice of fixating the source (what I > do) or the binaries (see below). > >> Guix has marvelous raw tools to do anything. The question is how to make >> it simple enough for someone that is basically an R user to take >> advantage of them. The challenge in guix R packaging is to consider R >> patterns of use and determine how guix packate R to support them in a >> way that is accessible to typical R users. > > What you need is a 'managed' environment for your users. My suggestion > is not to give guix daemon access to those users. Use Unix modules - > which I have packaged - to point them to a prepared profile. When they > want to use R, just make a profile. All modules do is set the PATHS, > as Roel described. Technology older than the Linux kernel :/ > > The 'manager' is the only one who will upgrade and test software to > run. That way you can do controlled upgrades. You can even have > multiple modules for different R's.
I imagine that, in the spirit of guix, we also want a user to be able to "help themself" instead of depending on a 'manager.' This would probably require an additional R "package manager component" that is usable by a manager or user. Such a thing would certainly showcase the unique capabilities of guix. > You are lucky you can run Guix daemon on your servers. Actually this is only fantasy at the moment, but I am hopeful.