[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnu: r: Update to 3.3.1.
From: |
myglc2 |
Subject: |
Re: [PATCH] gnu: r: Update to 3.3.1. |
Date: |
Sun, 31 Jul 2016 13:49:00 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Roel Janssen <address@hidden> 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 ;-)
Re: [PATCH] gnu: r: Update to 3.3.1., Andreas Enge, 2016/07/31