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.
