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

[Roel Janssen]

> 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?
>
> Hi George,
>
> If bioconductor tests pass on a new R build they *should* work. Guix
> is not the same mess that Debian and Fedora are.
>
> 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.
>
> Another way to work it is by using a checked out Guix source tree.
> That is what we do for Genenetwork deployment. Guix 'pull' simply
> represents a version of the source tree - with its combination of
> packages. You can force a combination of package versions by keeping
> track of your own tree. See 
>
>   https://github.com/genenetwork/genenetwork2/blob/master/doc/README.org
>
> 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

Hi George,

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.

>From a scientific viewpoint you cannot say that the results of your data
analysis "will work with R version 3.3.0 or higher", but instead you can
only say "we achieved these results b using R version 3.3.0, with
extension X at version Y" (assuming these versions can be uniquely
identified to their source code).  This is what you can do with GNU
Guix.

You could explain how to reproduce your results by writing:  "When using
the recipes from GNU Guix at Git commit XXXX, we can construct a
software environment including R with version Y, with which we can
obtain the results we obtained."

So, using any newer Git commit ID is not guaranteed to work (but is
likely to work..).  The cool thing is, is that you can construct the
software environment from any particular time, as long as the source
tarballs are available.

In addition to the `per-user' profiles, you could use `per-pipeline' and
`per-group' profiles for users to "pin" a specific software environment
for doing the data analysis.  Users can then set the environment
variables in their shell to use that shared profile:
  export PATH=/path/to/profiles/per-pipeline/ngs/guix-profile/bin:$PATH
  export 
R_LIBS_SITE=/path/to/profiles/per-pipeline/ngs/guix-profile/site-library

Or by simply following the recommendations by GNU Guix:
  guix package --search-paths 
--profile=/path/to/profiles/per-profiles/ngs/guix-profile

I think upgrading is inevitable, so pinpointing to a specific set of
build recipes (tied to a commit ID) is a good way of maintaining a
stable software environment.

Do you think we can keep the latest versions in the upstream repository,
provided that you have a way of reverting or staying to the "old"
versions by either copying the 3.3.0 recipe to a local repository, or
pinpoint to an older Git commit?

Kind regards,
Roel Janssen