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 16:14:54 -0400 Message-ID: <861t28i6v5.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> <86eg68cstn.fsf@gmail.com> <87vazknuk9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUJdh-0003XU-Gn for guix-devel@gnu.org; Mon, 01 Aug 2016 16:16:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUJdc-0000zY-1a for guix-devel@gnu.org; Mon, 01 Aug 2016 16:16:40 -0400 Received: from [195.159.176.226] (port=39869 helo=blaine) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUJdb-0000xr-Qe for guix-devel@gnu.org; Mon, 01 Aug 2016 16:16:35 -0400 Received: from list by blaine with local (Exim 4.84_2) (envelope-from ) id 1bUJdV-0005ek-CT for guix-devel@gnu.org; Mon, 01 Aug 2016 22:16:29 +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 Roel Janssen writes: > myglc2 writes: > >> Pjotr Prins writes: >> >>> On Sun, Jul 31, 2016 at 01:49:00PM -0400, myglc2 wrote: >>> >>>> 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. > > And users can! The "software manager" can provide "supported" profiles, > and the users can still create their own software environment. Then > when things break, users are one command away from switching to a > working environment (provided by the manager). This safety net provides > a confidence to play around even more.. > > The software manager can install packages from his own custom recipes, > separate from whatever `guix pull' provides by setting the > GUIX_PACKAGE_PATH variable. Users do not need to know about it, if they > don't want to. Yes I get that it is possible now... but I feel strongly that the typical R user will be overwhealmed by the guix "wheels and levers". So I resort to fantasizing a mythical additional guix-specific component, an 'R "package manager component"'. The idea is to exploit guix capabilities to make this much more tractable for an average R user and much more convenient for the sysadmin in charge of providing support to R users. Such an 'R "package manager component"' would make the argument for guix isntallation very compelling for medical research labs.