guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: r: Update to 3.3.1.


From: Roel Janssen
Subject: Re: [PATCH] gnu: r: Update to 3.3.1.
Date: Mon, 01 Aug 2016 21:44:06 +0200
User-agent: mu4e 0.9.17; emacs 24.5.1

myglc2 writes:

> Pjotr Prins <address@hidden> 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.

Kind regards,
Roel Janssen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]