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

[myglc2 <myglc2@gmail.com>]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote:
>> The workaround used by sysops where I work (hospital research lab) is to
>> give notice of R upgrades and to make previous releases available for
>> reference by ongoing projects. IMO, we should consider how the guix R
>> recipe(s) might support a pattern of use like this.
>> 
>> I can assure you that if our users do guix pull and invisibly get a new
>> R release, their analyses will from time to time break. So we may want a
>> simple way for them to back down to a previous release. So.. I am
>> thinking it would make sense to keep previous versions of R in the
>> recipe. What do others think?

> Note, meanwhile, that a new R install does not remove the old packages
> automatically. One way to work older versions is by using guix
> profiles effectively. We introduced Unix modules with Guix, so a
> module would point to a well tested and working profile. Just make
> sure it does not get GC'd at some point.

This functionality could be adequate in some situations if it can be
made simple to use. Some questions to answer...

What do you mean by "Unix modules"?

How does one "make sure it does not get GC'd"?

What happens when a user wants something else (e.g., not R) updated?

> Another way to work it is by using a checked out Guix source tree.

This is not simple and is beyond the capability of the medical
researchers I have met.

> In the near future I hope we get a version of guix pull which can
> essentially achieve the same (i.e. a checked out version of the tree).
>
>   guix pull HASH-tag

This comes the closet to being a "simple way for them to back down to a
previous release". It has merit independent of R.