Pjotr Prins <pjotr.publi...@thebird.nl> 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
