From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: R and R modules (and a Ruby twist) Date: Thu, 24 Sep 2015 11:40:57 +0200 Message-ID: References: <55FAA83C.3040403@uq.edu.au> <55FD2C91.9080203@uq.edu.au> <20150921073432.GA31971@thebird.nl> <87eghrlpi8.fsf@gnu.org> <20150924050800.GA10877@thebird.nl> <876130nu9m.fsf@gnu.org> <20150924083732.GA12554@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zf31Y-00058R-VD for guix-devel@gnu.org; Thu, 24 Sep 2015 05:41:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zf31W-0001jl-87 for guix-devel@gnu.org; Thu, 24 Sep 2015 05:41:08 -0400 In-Reply-To: <20150924083732.GA12554@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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins Cc: "guix-devel@gnu.org" Pjotr Prins writes: > When we add an R module, such as R-qtl, the R-build-system does not > provide R itself as a propagated input, i.e., the R interpreter is not > in the profile. In the R world this is kinda odd. Almost all modules > used from R. I.e. start up R and > > library(qtl) > do something with R/qtl > > Would have use people use that module in interactive mode. In the > current package install R is not included as a symlink and needs to be > separately installed. Correct. I didn=E2=80=99t think of it as a problem as I assumed people w= ould have R installed in their profile if they wanted to interactively use an R package. But now that you mention it, I think it might lead to problems (see below). > It is one other thing I am trying to think through. With a standard R > distribution, every package is strictly aligned with the interpreter > (they get installed from inside R). > > With Guix' rolling model of package updates modules may go out of sync > - even if they are correctly linked with an underlying R. So mixing > interpreters and modules/packages may potentially give problems.=20 Users can have any number of =E2=80=9Clibraries=E2=80=9D (directories con= taining installed R packages) in R_LIBS_SITE. Currently, our R package suggests R_LIBS_SITE to be set to =E2=80=9C$profile/site-library=E2=80=9D and the = r-build-system installs packages to =E2=80=9C$out/site-library=E2=80=9D. We could add a level for the R version, e.g. =E2=80=9C$out/site-library/3= .2.2/=E2=80=9D, but it should be noted that R_LIBS_SITE makes no distinction for different versions of R. It=E2=80=99s just a single list of directories.= I don=E2=80=99t know what would happen if you had R_LIBS_SITE=3D$HOME/site-library/3.2.2:$HOME/site-library/3.1.3 and then ran one or the other version of R. (Note that currently there can only be one version of R in a single profile anyway.) I guess the problem is with updates. If you had R 3.1.3 in your profile and installed a new R package that is then built with the latest version of R (3.2.2), this might lead to problems actually using the package in an R session using version 3.1.3. Maybe it would be best to append the R version to the site-library directory. I don=E2=80=99t think we should go further than that and brin= g in the Guix hash, because I=E2=80=99m willing to trust that packages built w= ith version 3.2.2 are compatible with R 3.2.2, even if the inputs to our R package changed and thus the hash is different. ~~ Ricardo