From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Sun, 31 Jul 2016 11:45:02 +0200 Message-ID: <87popup2e9.fsf@gnu.org> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> <20160731040956.GA22271@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTnIc-0003oI-Na for guix-devel@gnu.org; Sun, 31 Jul 2016 05:44:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTnIW-0008KQ-Na for guix-devel@gnu.org; Sun, 31 Jul 2016 05:44:45 -0400 In-reply-to: <20160731040956.GA22271@thebird.nl> 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: myglc2 Cc: guix-devel@gnu.org > 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