Ping @mboes

I think that's selling Stack a little short. Certainly it's intention is to be a production tool, not just a dev tool. It is quite often used to build production deployments with it. The whole selling point is that it makes build reproducible. The only significant source of actual nondeterminism that I can think of is the ability to specify a branch for a git-based extra-dep instead of a revision. But that's generally considered bad practice.

I understand that there are significantly more points of failure (in terms of reproducibility) with anything as heavily networked as Stack, but I do believe that nondeterministic builds are the outlier with it. I don't consider it worse than the other common forms of nondeterminism in Nix, like builtins.fetchTarball.

Granted, I'm a bit biased, as I don't even use Stack this way exactly. I do nutty stuff like this:

{ }:

let
  nixpkgs = import ./nixpkgs {};
in nixpkgs.haskell.lib.buildStackProject {
  ghc = nixpkgs.haskellPackages.ghcWithPackages ...; # Not the GHC given by stack!
  ...
}

The nice thing about this is that I set the resolver to ghcXXX, which is a resolver with zero packages included, and Stack will just use the packages selected by my Nix expression since they're effectively baked into the GHC. This makes the nix-build more like a normal Haskell derivation, and I get the nice developer experience with the Stack CLI.

LGTM. Except for the preferLocalBuild thing, which to me looks orthogonal to the other changes, and could be discussed separately. cc @YPares

@mboes @peti @domenkozar I've removed the preferLocalBuild thing. Will open a separate PR for discussion on that particular topic. Does this look good to go?

LGTM

Can we merge this please?

Thanks!

Is it normal that stack need to download build plan every time I call nix-buildeven there is nothing change and the last build was success?

@wizzup Yea. Having the ability to use this with nix-build is nice, but it's not super user friendly. We could resolve this by making the STACK_ROOT a derivation of its own, such that it only has to be rebuilt when the stack.yaml changes. In fact, we could even then let nix check parts of that derivation against a hash to help reassure the purity of it.

I am fine with dropping in nix-shell and run stack build while making changes.