__NoChroot error trying to integrate stack build into NixOS configuration.nix

I’m a fairly competent Haskell developer, but brand new to nix.

I have a NixOS machine, which I’ve hitherto managed to configure nicely, mostly by using various recipes etc.

While I’m still working on climbing up the nix learning curve, I’ve had a need to build and deploy a Haskell yesod app.

As I’m quite familiar with stack, I figured I’d reach for that first, as it has a nix integration. I was fairly quickly able (apparently) to build my project with the nix integration. I realize that it doesn’t have all the advantages of incremental building and caching of the dependency artefacts, but it’s the path of least resistance to me.

My shell-file (default.nix) is just the one suggested in the stack docs:

{ghc}:
with (import { });

haskell.lib.buildStackProject {
inherit ghc;
name = “scoti2”;
src = ./.;
buildInputs = [ openssl postgresql zlib ];
}

However, when it came time to integrate this into my NixOS configuration.nix, I thought I’d pull the project in from its repo and put this prefix in that file:

let
scoti2Project = builtins.fetchGit {
url = “”;
rev = “”;
# Or you can use fetchSubmodules = true; if your project uses Git submodules.
};
myScoti2 = pkgs.callPackage “${scoti2Project}/default.nix” {};

… and I then use myScoti2 later in the configuration.nix (specifically in an attempt to configure the keter service).

The problem I’m getting is the error:
error: derivation ‘/nix/store/yasp23bhaqc53l508xdki8iq24aalxf7-scoti2.drv’ has ‘__noChroot’ set, but that’s not allowed when ‘sandbox’ is ‘true’

It is my understanding that stack uses a non-sandbox build method in order to give it the freedom to use the network during the build process in order to satisfy dependencies by downloading packages from the internet, and this is why __noChroot is set, but that this is incompatible with the outer build context of my configuration.nix.

Not having the required nix-fu (yet!), I’m rather stuck. An amount of googling around hasn’t really revealed the answer either, so I’m asking for help here.

Is there any way to somehow separate the part of the build that will be done by stack, from the part that seems to be want the sandbox build somehow?.. or perhaps some other nix magic? Or maybe I’m just living wrong and somebody can correct my errant ways :slight_smile:

Thanks in advance.

– Luke

To get past your immediate error, you can use the Nix option --option sandbox relaxed. This turns off the sandboxing for your Stack build.

Although, most people using Haskell with Nix don’t use the generic stack builder from Nixpkgs. One of the main reasons is the requirement that you turn off sandboxing!

So what are your options for building Haskell projects with Nix? I have a small list here:

If you absolutely want to build a stack-based project with Nix, you have three main options:

  1. Pick a version of Nixpkgs that uses the same LTS version your project is based on, and then use haskellPackages.developPackage or haskellPackages.shellFor for building your project.

  2. Use haskell.nix. This has very good support for building from a stack.yaml file. The downside is that it can be quite complex.

  3. Use stacklock2nix. This is a little simpler than haskell.nix (although I’d hesitate to say that it is “beginner-oriented”).

Thanks! I had come across the “Super-Simple Haskell Development with Nix” in my googling, but thanks for bringing me back to that.

Looks like I’m fated to wade deeper into nix and I should probably just jump in with both feet, but of course I’m looking for the path of least resistance. I’ve been meaning to migrate back to cabal after years of preferring stack (as cabal has now improved in leaps and bounds), and I suppose learning to use nix more deeply might also be a part of rebasing my Haskell build skills.

However… your first comment seems interesting and is perhaps worth a follow up question:
As I’m building on NixOS, with the reference to my Haskell project pulled into my configuration.nix, I’m using nixos-rebuild to quick everything off. I note that there’s no --option sandbox relaxed at this level (at least based on the nixos-rebuild help), so is there a way to assert this in a configuration somewhere, that nixos-rebuild will see and apply to the whole system, or can this be asserted just for my project itself. The answer would seem to be no as this is how I get into the problem to begin with… stack is obviously asserting that it needs things that don’t work in a sandbox build, but the outer build context is already in a sandbox.

The old-style Nix commands’ man pages leave a lot to be desired. I think --option sandbox relaxed does work for nixos-rebuild.

In order to test this, I added the following to my NixOS configuration:

  environment.systemPackages = with pkgs; [
    ...
    (runCommand "hellohello" {__noChroot = true;} "mkdir -p $out/bin && touch $out/bin/hellohello")
  ];

Trying to build this normally gave me the error as expected:

$ sudo nixos-rebuild build
error: derivation '/nix/store/vsz7pfmz16534v3hphsrsjkc5qw13h71-hellohello.drv' has '__noChroot' set, but that's not allowed when 'sandbox' is 'true'

Rebuilding with --option sandbox relaxed worked:

$ sudo nixos-rebuild build --option sandbox relaxed

You can also specify this sandbox = relaxed option in your /etc/nix/nix.conf (which on NixOS I believe is created with a separate NixOS option). I imagine the NixOS manual has instructions how to set Nix-specific options.

(edit: Oh, and I guess I should add again that most people don’t run with sandbox = relaxed, because it is generally safer / better to do builds in the sandbox!)