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

[myglc2 <myglc2@gmail.com>]

Roel Janssen <roel@gnu.org> writes:

>> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote:
>>> 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?

> 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.

> 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).

Actually R 'sessionInfo()' collects this at run time.

> 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.

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.

> 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?

Guix in general should have a scheme to decide which "golden oldies"
stay in the repository ;-)

In the meantime, after thinking about it some more I withdraw the
suggestion of multiple R version recipes (please see separate post).

But maybe you should test the existing guix R package recipes against
the new R version, if you have not already done so, before you update
the R recipe ;-)