Change:
in stdenv.mkDerivation (args // { <ins> # Doesn't work in the sandbox. Pass `--option sandbox relaxed` or # `--option sandbox false` to be able to build this __noChroot = true; </ins> buildInputs = buildInputs ++ lib.optional (stdenv.hostPlatform.libc == "glibc") glibcLocales;

Discussion:
According to it should now be possible to use to build a derivation. This however doesn't seem to work due to stack failing to download the resolver build plan: This is the same error as in from before the new , which was closed without a solution. Pinging the participants of these two issues and Create new stack project: Add a with the contentsAdd the following to :Build (with latest master):system: host os: multi-user?: sandbox: version: channels(infinisil): channels(root): nixpkgs:
Related?
I guess it makes sense: The nix sandbox doesn't allow networking for non-fixed-output derivations. As expected, turning off sandboxing makes it work: The resolver build dependencies should be downloaded with a fixed-output derivation instead, but I'm not sure how to do that. Will tinker with it though.
I'd say this issue is valid. I believe the stack home can be a fixed output derivation, which would actually be enough to change the thing.
Er, actually no. Though I bet Stack's build plan is 100% deterministic, GHC is not. So the libraries Stack builds won't be fixed. Ugh.
I wonder if you can get stack to do the 100% deterministic build plan as a fixed output derivation, do the actual Haskell dependency building as another derivation, and finally have the stack project on top of all that. EDIT: wording
Unfortunately, 's build plan is not 100% deterministic due to the wonders of destructive editing on Hackage. New revisions of a published package can modify the version constraints on dependencies and therefore affect the set of packages required for the build.
I thought Stackage had a bunch of stuff to deal with that? I don’t have a source; just vaguely remember some rants on Stack issue pages about this stuff.
If it does, then I am not aware of it.
So newer resolvers do pin revisions, but older ones do not. Also I believe that never have their revisions pinned Nevertheless, I think we can fix all of this by pinning the Hackage DB version that stack looks at.
I'm going to reopen this issue because this should at least be documented in the manual.
Please don't keep this issue open. If you feel like there should be documentation of the status quo, then please don't hesitate to submit a PR that extends the documentation.

Keeping old issues open that nobody has acted upon for 1+ years is no good way to accomplish anything. Doing it is a good way to accomplish things you are about.
This issue is not resolved and the issue description is still as valid as it was when I opened it, as already mentioned by a while ago. I've reopened this because I just had to explain to a user on IRC how doesn't work with the sandbox. We can't just close issues because nobody has currently time to work on it. We're all busy here, but issues don't go away because of that.
No-one disputes that this issue exists. It does. But that does not mean that we need to track it in the Nixpkgs bugtracker as an open issue. We cannot possibly have an open bug in here for every single use case that some person somewhere in the world might think of. It's too much noise and it drowns out that issues that are more important.
This isn't a random usecase though, it's the way to have a Nix build for a stack project. By keeping it open it serves as a ToDo item, for nixpkgs maintainers and myself, this gets forgotten otherwise, and indeed I did already forget about this because you closed this a while ago, yet the problem is still not solved or even remedied. Closed issues are for "won't fix" or "not an issue" or "issue is fixed", and not "don't want to fix right now".
Some excerpts from #nixos: : : : That's at least 4 known people (with the person in , which you also closed) to have had this issue. And I think it's fair to double this to include instances I couldn't find. That's a significant number. Do we close issues for [insert random software here] because the single person using it encounters an issue with it? No. Then we also shouldn't close this issue which is a problem for an order of magnitude more people.
Would a good approach be to have take a hash for the stackage snapshot (like etc), in which case we can allow ourselves impure downloads?
The issue is in determining what exactly to hash. Stack needs to download info from Hackage to build a plan, but this info is ever-changing, as the Hackage index changes.

So you have to somehow hash the plan that Stack comes up with, and that plan needs to be 100% deterministic (unclear whether it really is, given ). This fixed-output derivation also needs to include all the package source tarballs you'll need, since those need to be downloaded and hashed as well. And you have to do all that without allowing Stack to build any of the libraries, because GHC is nondeterministic and would ruin the hash. The simplest thing for the plan part would be somehow controlling the Hackage index tarfile that Stack uses. This tarfile is append-only, with new entries having a later date, so simply truncating it on a date set in the recent past can make a fixed-output derivation. If Stack can be told to use this tarfile, the plan can be constructed without internet access. But this doesn't include source hashes, so you'd need either IFD, or a separate derivation with a separate user-supplied hash to represent all the required sources. It's a mess.
Reopening so I can close it with a PR that actually addresses this..