From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Sun, 31 Jul 2016 13:49:00 -0400 Message-ID: <8660rllmur.fsf@gmail.com> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> <20160731040956.GA22271@thebird.nl> <87popup2e9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTut9-0001nP-9H for guix-devel@gnu.org; Sun, 31 Jul 2016 13:51:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTut3-0002Wr-Fs for guix-devel@gnu.org; Sun, 31 Jul 2016 13:50:58 -0400 Received: from blaine.gmane.org ([80.91.229.8]:60820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTut3-0002VP-8g for guix-devel@gnu.org; Sun, 31 Jul 2016 13:50:53 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bTusw-0008RA-JG for guix-devel@gnu.org; Sun, 31 Jul 2016 19:50:46 +0200 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Roel Janssen 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 ;-)