Using Nix to Create R Virtual Environments

Previously we saw how to use Nix to create virtual environments for Python. We can do the same for R. This means we can have different simultaneous R installations for different projects and keep the installed packages for each project separated. An important benefit of this is the ability to have different (incompatible) versions of the same packages for different projects.

The straightforward approach is to let Nix handle all R package management. However, sometimes it is useful to manage packages through the various R tools such as the built-in install.packages or install utilities provided by the devtools package.

R looks for installed packages in the R library directories, of which there are two types: the system library and the user library. By default these package management tools install packages in the first-specified user library directory. The user library directories can be specified through the R_LIBS_USER environment variable. We can use Nix to specify a unique library directory per project.

For example, create a in your project root as follows:

with import <nixpkgs> {};
  my-r = rWrapper.override {
    packages = with rPackages; [ 
  pkgs.mkShell {
    buildInputs = [
    shellHook = ''
      mkdir -p "$(pwd)/_libs"
      export R_LIBS_USER="$(pwd)/_libs"

Activate it in your shell by running $ nix-shell.

This makes available R with ggplot, plyr, tidyr and devtools. It creates a subdirectory in your project root, _libs, where the project’s R user library is located.

Using Nix to Create Python Virtual Environments

Nix and Python logos

Nix is a great tool to set up development environments. It allows us to have simultaneous installations of various versions of tools—such as Python—required for our projects. This means Nix makes it easy to have Python 2.7 installed for one project, and Python 3.6 for another. Projects using the same Python version can have different Python packages.

Of course, Python’s VirtualEnv also enables us to do this. Nix, however, is more powerful. It can handle all our system’s packages; not just Python’s. This means it enables us to hold different versions of any dependency. For example, if one project requires a specific version of OpenCL and another project requires an incompatible version, VirtualEnv won’t help us. Nix will.

There are many Python packages, and to install one such package through Nix requires it to be available in the Nix package repository. Understandably, not all Python packages are packaged for Nix—and those that are, often are not the newest version, nor at some other specific version we require.

We can use Nix to provision a Python environment for our project that works similarly to VirtualEnv’s. We can then use pip to handle such per-project Python dependencies, allowing us to grab Python packages directly from the regular Python package repositories without going through Nix. This also allows us to quickly get to work with others’ Python projects that are not set up to work with Nix.

Continue reading “Using Nix to Create Python Virtual Environments”