Change:
STACK_PLATFORM_VARIANT="nix"; STACK_IN_NIX_SHELL=1; <del> STACK_IN_NIX_EXTRA_ARGS = concatMap (pkg: ["--extra-lib-dirs=${getLib pkg}/lib" "--extra-include-dirs=${getDev pkg}/include"]) buildInputs ++ extraArgs; </del> <ins> STACK_IN_NIX_EXTRA_ARGS = extraArgs; shellHook = '' for pkg in ''${pkgsHostHost[@]} ''${pkgsHostBuild[@]} ''${pkgsHostTarget[@]} do [ -d "$pkg/lib" ] &&  export STACK_IN_NIX_EXTRA_ARGS+=" --extra-lib-dirs=$pkg/lib" [ -d "$pkg/include" ] &&  export STACK_IN_NIX_EXTRA_ARGS+=" --extra-include-dirs=$pkg/include" done ''; </ins> # XXX: workaround for https://ghc.haskell.org/trac/ghc/ticket/11042. LD_LIBRARY_PATH = makeLibraryPath (LD_LIBRARY_PATH ++ buildInputs);

Discussion:
I am working on a Haskell project that uses . Compiling the project fails with: From my limited understanding of Nix, header files are stored in and is not there.
The default does not include the development headers. Try running from a nix-shell:
Thanks for the response. I tried and then . This resulted in the same error as before. Could you please explain why we'd expect using to work in this case? Is there a simple modification that can be made to the derivation so that it includes the development headers or would creating an entirely new derivation, perhaps named , be a better option?
Ok sorry forgot, that you probably need to do this: Which is working for me at least. Alternatively, you should be able to call stack with the --nix arg. (Sadly it does not work currently with GHCJS):
I have actually gone down the + route. I created a file: and to my file. This resulted in the same error as above. This is why I've gone back now to just using to see if I could get it to work in this more simple setting and then try later on. Just now I tried your suggestion and this also resulted in the same error.
It must be something weird going on with Stack. You definitely shouldn't have to manually install gpgme. Anyway, bindings-gpgme is working for me:
The above worked for me. It finished by printing out . It did also say ; now sure what that means. Any ideas on why this works but doesn't when I just install by itself? I'm guessing somewhere in the Nix machinery it knows depends on and so it installs it in a specialized way? At the moment I'd like to avoid having Nix manage all the haskell packages. My goals is to slowly move the organization I work at towards Nix. I think a good first step would be to provide developers with a reproducible development environment that contains all the non-haskell deps.
I was able to get the integration to work with the following: Turns out what I needed was which is explained in the documentation . I still wish there was a way to get this to work without having to rely on a feature.
That's very weird! We should be doing this for you in buildStackProject: I get this with :
Ok- I might have found the problem.

Try this , You need libgpgerror for the gpgme header to work properly. Update: It looks like we are not properly propagating inputs to generic-stack- is not being pulled into despite being necessary for gpgme.h to work (and a propagated input). /cc
I've never looked at . it might be screwed up in arbitrary ways.
Is there any kind of tool to pull in the deps that Nixpkgs would with buildInputs? I think does this but it would be nice to avoid having a script. Something like this: where findAllInputs includes propagated dependencies.
Yeah mutates all these globals cause bash so it's very inconvenient to call more than once. Maybe try dredging up and updating it work as does today :D. This won't be quite the same as there's a few cases of packages hand-modiying the propagated input files .
but a far easier solution is just to loop over in bash (or add an env hook to let the looping be done for you).
Hmm... I guess we will need to put it in shellHook too for it to work with . The problem with the env hook is that gpgme shouldn't have to know Stack exists at all. It might make more sense to just replace NIXLDFLAGS & NIXCFLAGS_COMPILE directly to emulate cc-wrapper behavior (which stack should be calling anyway right?) Has anyone looked into rewriting all headers to give absolute path names for calls? That would solve most of these build cases I think & Nix would treat them like it does dynamic libraries. Probably a huge change but could be worth doing & avoids some of the propagated cases where it really just needs the header file (not all though).
Ahh but can add the env hook, and everything will work out.
That would be really cool! But CPP sadly makes these things quite hard. Because (CPP) identifiers are ambiguous, one would have to bail out on the first unresolved as further name resolution is ambiguous.
I to the and removed the line. This worked. Thank you. However, if I use in place of or if I work outside of a , installing and with , my haskell project does not compile and results in the same error that I initially posted. Is this to be expected? If so, can you please explain why?
Awesome!

So when you run it will symlink things into . By default, Nix will set some variables like PATH & MANPATH to pick up things in $, but we don't intend to set up too much besides these "standard" variables. Instead, we prefer to do things inside (which I think is also what uses) that are closer to how Nixpkgs are built. Here is maybe what you wanted to do originally (which still works but gets ugly with lots of dependencies): Hopefully we can fix the issue with propagation though.
Thanks for the explanation. So it seems my idea of using to build a general purpose development environment doesn't really align with what the tool was intended to be used for? And just to confirm, the "issue with propagation" relates only to ?
Is this what you were thinking? I am not able to get the setupHook route to be run correctly in nix-shell so the addEnvHooks doesn't work.