Library paths leaking (?) into R dev shell

Help
1

Referencing R sf package can't find shared library but the root problem. The issue is that the .libPaths() in the nix R session have a path to my global R library at the top, causing nix R package load to fail:

> .libPaths()
 [1] "/home/michael/R/x86_64-pc-linux-gnu-library/4.3"
 [2] "/nix/store/2sjlgab913pjh63qkydijz7zc2298l9d-r-box-1.2.0/library"

I tried looking for global files that could read some file or an environment variable being set, but could not find anything, and resolved to clumsily setting the environment variables to the local directory.

Who or what is setting this first path?

I have R installed globally on Ubuntu, and a nix flake with the following contents, with R_LIBS* set to a dummy path.

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
  inputs.flake-utils.url = "github:numtide/flake-utils";

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        rPackages = pkgs.rWrapper.override{
          packages = with pkgs.rPackages; [
            box
            languageserver
          ];
        };
      in {
        devShells = {
          default = pkgs.mkShell {
            nativeBuildInputs = [ pkgs.bashInteractive ];
            buildInputs = [rPackages];
            shellHook = ''
              export R_LIBS=.
              export R_LIBS_USER=.
              export R_LIBS_SITE=.
              export LC_ALL=C.UTF-8
            '';
          };
        };
      });
}

Any help would be greatly appreciated!

2

I’m not certain, but while testing some R things today I noticed that that path with the machine type and R version did not exist for me at first - on Ubuntu - but did when I installed an R package via install.package('packagename') where R then prompted me saying something like “Library not writeable , would you like to create a User Library?” which I said “yes” to.

I think this is documented here:

When you set export R_LIBS_USER=. that should stop that home directory library from appearing.

Are you sure you are opening that devshell when you launch R?

As your situation would make sense if you were running R outside of that devshell, meaning R_LIBS_USER is probably set to that path. You could check with env | grep R_LIBS outside of the devshell.

3

Yes that’s what I did now. I just thought the nix R installation would take care of this isolation part itself somehow, since as it is, it looks like it just will happily use whatever you have installed in a non-nix R installation, this feels a bit hacky, no?

4

Yes that’s what I did now. I just thought the nix R installation would take care of this isolation part itself somehow, since as it is, it looks like it just will happily use whatever you have installed in a non-nix R installation …

Based on the flake expression in your original post, you have described a devshell which contains bash, rPackages, and exports some R envvars, and a locale envvar. This isn’t installed anywhere just by writing that expression.
If you run nix develop in the directory that contains that flake, then you will have those envvars set as you expect. At this point, if you run R, you will probably get your global R installation - not sure if you installed that via nix, or apt-get etc.
If you were expecting to get R in that devshell provided by nix, the reason you don’t is that rPackages doesn’t include the R binary. As that isn’t an R package (it can’t be loaded into R, it is R!).
If you add R to your buildInputs, you will have R provided by nix in that devshell.

The R provided by nix might have some kind of override to avoid using that home directory library path, but I think that is unlikely. You talked about “taking care of the isolation part” - nix the package manager takes care of isolating/sandboxing the build process - not the runtime process. By default, binaries built with nix can access the same parts of your filesystem that a binary from apt can.

If you want runtime sandboxing, you can achieve that with nix in some situations, but you might be better served by non-nix techniques like docker, systemd containers, etc.

To answer what I think you are trying to do - have R not load that home directory based library path - you need to launch R with the appropriate environment variables set - like you are doing in your devshell.

Or, just delete that directory, and next time R asks you if you want to save a user library (if it happened the same way as mine) decline that option.

this feels a bit hacky, no?

Now that I’ve explained that nix isn’t designed to provide runtime isolation by default, you might not see this as hacky. Instead, I would say that nix (and in particular using nix with R and devshells) is not the complete solution for your use case.

You might try using nix to build an environment (via devshell, or buildFHSEnv) within a docker container and run R within that container - it won’t have access to your main filesystem by default, giving you a decent level of isolation.

5

Oh and I’ll just add that another thing you might want to look at is nix-shell - it can be used much like nix develop, but it supports a --pure option which means only the build inputs you specified will be available. However, that shell can still access the entire filesystem just like any other process can.