[Nix-dev] [nix-dev] Re: Developing R modules with nix

Peter Simons simons at cryp.to
Wed Sep 17 18:48:18 CEST 2014


Hi Michel,

 > is this the preferred way to declare user-packages?

I'm not sure whether any particular way to declare user packages is
preferred over another, but it certainly is important to distinguish
between 'super' and 'self' when configuring the set of overrides. What
exactly you do with those overrides is up to you -- that's the beauty of
using a powerful language like Nix to configure your system. Whatever
works for you is probably just fine.


 > Could you argue about benefits or drawbacks of the *Wrapper

The wrapper gives you a deterministic configuration. You pick the set of
modules that R knows about, and R will always know those modules
regardless of what other packages you have or haven't installed in some
other place. The wrapper also doesn't need any environment variables to
be configured, etc. If you execute scripts that depend on modules you
haven't declared, then R will fail until you add them to your config.nix
and update R to pick them up. This is more effort to set up in the
beginning, but it gives you a system that's extremely reliable and
easily reproducible.

If you install modules into a user profile via nix-env, then you need to
tell R how to pick those modules up. If that path ever changes, then
those modules suddenly disappear from R. The set of modules that R knows
or doesn't know isn't deterministic: it depends on the state of some
other resource that Nix doesn't control.

Personally, I configure the R wrapper to contain all modules that I
regularly use. When I want to try out a new module, I install it from
within R via install.packages() into my $HOME directory and play with
it. If it works fine, then I add it to the wrapper and erase $HOME/R. If
it turns out I don't want that module, then I just erase $HOME/R. I
never install R modules directly in a profile via Nix. That's just me,
though, your mileage may vary.

I hope this helps,
Peter



More information about the nix-dev mailing list