R and R modules (and a Ruby twist)

[Pjotr Prins]

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.

Is this really a good idea? 

Personally I think R should be in the path because that is the only
way a module is useful to 99% of users.

We can actually instruct users to install R separately (no different
from other packaging systems). Note that this opens its own can of
worms when the two are out of sync. I can imagine Guix modules having
different R's as dependencies.

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. 

The Ruby twist:

With Ruby we use the major version numbering of the interpreter to
share modules (named gems) - i.e. anything 2.2.x gets installed in the
profile under 2.2.0 - this is the default model in the Ruby world. I
am actually not completely happy with this model because it does not
isolate interpreters and the installed gems. Even though it `works' in
almost 100% of use cases. What happens now, for example, is that a
Ruby with ssl and and Ruby without ssl always share gems. This is
pretty evil. I would prefer incorporating the SHA value of the
interpreter in the Guix profile to host gems. That would guarantee
perfect isolation and is pretty easy to achieve.

Pj.