[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: R and R modules (and a Ruby twist)
From: |
Ricardo Wurmus |
Subject: |
Re: R and R modules (and a Ruby twist) |
Date: |
Thu, 24 Sep 2015 11:40:57 +0200 |
Pjotr Prins <address@hidden> 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’t think of it as a problem as I assumed people would
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.
Users can have any number of “libraries” (directories containing
installed R packages) in R_LIBS_SITE. Currently, our R package suggests
R_LIBS_SITE to be set to “$profile/site-library” and the r-build-system
installs packages to “$out/site-library”.
We could add a level for the R version, e.g. “$out/site-library/3.2.2/”,
but it should be noted that R_LIBS_SITE makes no distinction for
different versions of R. It’s just a single list of directories. I
don’t know what would happen if you had
R_LIBS_SITE=$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’t think we should go further than that and bring in
the Guix hash, because I’m willing to trust that packages built with
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
- [PATCH] Add python2-seqmagick., Ben Woodcroft, 2015/09/17
- Re: [PATCH] Add python2-seqmagick., Ricardo Wurmus, 2015/09/17
- Re: [PATCH] Add python2-seqmagick., Ben Woodcroft, 2015/09/19
- Re: [PATCH] Add python2-seqmagick., Pjotr Prins, 2015/09/21
- Re: [PATCH] Add python2-seqmagick., Ludovic Courtès, 2015/09/21
- Re: [PATCH] Add python2-seqmagick., Ben Woodcroft, 2015/09/21
- Re: [PATCH] Add python2-seqmagick., Pjotr Prins, 2015/09/24
- Re: [PATCH] Add python2-seqmagick., Ludovic Courtès, 2015/09/24
- R and R modules (and a Ruby twist), Pjotr Prins, 2015/09/24
- Re: R and R modules (and a Ruby twist),
Ricardo Wurmus <=
- Re: R and R modules (and a Ruby twist), Pjotr Prins, 2015/09/24
- Re: R and R modules (and a Ruby twist), Ricardo Wurmus, 2015/09/25
- Re: [PATCH] Add python2-seqmagick., Ricardo Wurmus, 2015/09/25
- Re: [PATCH] Add python2-seqmagick., Ben Woodcroft, 2015/09/25
- Re: [PATCH] Add python2-seqmagick., Ricardo Wurmus, 2015/09/28
Re: [PATCH] Add python2-seqmagick., Cyril Roelandt, 2015/09/21