Nixpkgs: Impossible to write a derivation for a stack application

[canndrew]

I have a haskell application that uses stack as its build system. Building this application is as simple as it gets - just cd into the source directory and stack build. It doesn't seem possible to write a Nix package for this application.

Using buildStackProject fails due to #32005, ie. it can't find /etc/protocol inside the nix build sandbox. If try to just stdenv.mkDerivation with buildPhase = "mkdir $TMP/build; stack build --stack-root=$TMP/build it fails the same way. Adding the iana-etc package which supplies /etc/protocols to my package's buildInputs doesn't fix the problem unless I also use libredirect to direct open calls to /etc/protocols to the correct location. After that though stack is still unable to download the files it needs, this time due to DNS resolution not working. I gather this is by design since Nix derivations aren't supposed to download arbitrary files off the internet without specifying a content hash, so at this point I abandoned the idea of calling stack directly.

I then discovered stack2nix which supposedly generates a nix package from a stack.yaml. It works, except that the default.nix it generates is 49194 lines long and seems to include build instructions for every haskell package in existence, so I can't really include it in nixpkgs. I also tried stack2cabal thinking I could make a package that converts the application's build system to cabal and builds from there, but the package for stack2cabal is broken and won't install.

At this point I'm out of ideas. I'm surprised that this is so difficult given that Nix and stack have such a large intersection of users and that stack even has some built-in support for Nix. At any rate, I think it should be considered a bug that there's no simple way to do this.

[arianvp]

Incidentally had the same issues few days ago and I stumbled upon https://input-output-hk.github.io/haskell.nix/ which seems to be better designed than the current Haskell nix infrastructure but is currently a separate project from Nixpkgs. It did build my stack project successfully though.

[arianvp]

Also, if buildStackProject doesn't even build without sandboxing perhaps it shouldn't be in nixpkgs and we should instead point people to better alternatives in the docs.

[peti]

Nix does not support building packages with Stack. There are several hard problems that would need to be fixed and I am not sure whether anyone is actually working on that. At the moment, the build system of choice is Cabal.

[arianvp]

buildFromStackProject is in the official documentation so it seems like a bit of rude to just close this issue with "this is unsupported". Why is is documented in the first place than?

Especially after me suggesting to fix this situation by updating the documentation and removing the code from Nixpkgs. Please reopen this.

[samueldr]

Re-opening to get a closure on the buildFromStackProject issue. (And as asked by @arianvp)

[arianvp]

Reading the docs a bit more closely it technically only mentions that it should be used to create nix-shells but perhaps we should revert https://github.com/NixOS/nixpkgs/pull/30072 such that the derivation can't be used with nix-build if we don't plan on maintaining that usecase

[peti]

buildFromStackProject is intended to be used in interactive development environments, i.e. in nix-shell. It's not intended to be used to build stack packages within Nixpkgs.

[arianvp]

Could we rename the thing to the more semantically honest shellForStackProject at least? Such that people stop running into this?

[peti]

Personally, I wouldn't mind, but others might feel strongly about this. Feel free to propose a PR, though, to trigger some kind of discussion.

[arianvp]

I'll think about it a bit more. Maybe it causes too much breakage to change the name. I'll definitely PR something to improve the docs a bit sometime this week.

[jamesdbrock]

To anyone reading this: I was having a similar problem, and I found the instructions at the bottom of this page:

https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats

and set these environment variables in my derivation:

NIX_REDIRECTS = "/etc/protocols=${self.iana-etc}/etc/protocols";
LD_PRELOAD = "${self.libredirect}/lib/libredirect.so";

and that worked for me.