From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Mon, 01 Aug 2016 13:17:08 -0400 Message-ID: <86eg68cstn.fsf@gmail.com> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> <20160731040956.GA22271@thebird.nl> <87popup2e9.fsf@gnu.org> <8660rllmur.fsf@gmail.com> <20160801060032.GB26920@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUHKl-0000ZW-RJ for guix-devel@gnu.org; Mon, 01 Aug 2016 13:49:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUHKg-0004sd-El for guix-devel@gnu.org; Mon, 01 Aug 2016 13:48:58 -0400 Received: from [195.159.176.226] (port=46225 helo=blaine) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUHKg-0004rM-6t for guix-devel@gnu.org; Mon, 01 Aug 2016 13:48:54 -0400 Received: from list by blaine with local (Exim 4.84_2) (envelope-from ) id 1bUGrX-0003CS-RD for guix-devel@gnu.org; Mon, 01 Aug 2016 19:18:47 +0200 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Pjotr Prins 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.