Roel Janssen <r...@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 ;-)
