ghc-mod doesn't work with Stack

[chris-martin]

> stack exec -- ghc-mod check Foo.hs
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
Cabal. Use the flag --package-db to specify a package database (it can be used
multiple times).
ghc-mod: readCreateProcess: cabal "configure" "--with-ghc=ghc" (exit 1): failed

> stack --version
Version 1.0.2 x86_64

> stack exec -- ghc-mod --version
ghc-mod version 5.4.0.0 compiled by GHC 7.10.3

I've been trying to get any Haskell editor set up, and so far this has blocked me from using Haskforce and SublimeHaskell.

[silky]

How did you install ghc-mod? I just installed it with stack install ghc-mod outside any stack project, and it used resolver lts-5.0, and installed fine, and runs fine for me.

I got ghc-mod 5.5.0.0, though.

[chris-martin]

I haven't done anything to install ghc-mod. I'm using --nix. Here's my stack.yaml:

resolver: lts-4.2
packages:
- '.'
extra-deps: []
flags: {}
extra-package-dbs: []

nix:
  enable: true
  packages: [glpk, pcre, zlib,
             haskellPackages.cabal-install, 
             haskellPackages.hdevtools]

[mgsloan]

Use stack exec --no-ghc-package-path -- ghc-mod to fix that. It's unfortunate that Cabal throws an error when it encounters GHC_PACKAGE_PATH instead of using it...

[chris-martin]

After adding --no-ghc-package-path, the output is:

cabal: At least the following dependencies are missing:
Decimal -any, aeson -any, split -any, text -any, wreq -any
ghc-mod: readCreateProcess: cabal "configure" "--with-ghc=ghc" (exit 1): failed

Is Cabal not receiving the package path at all now?

[mgsloan]

Looks like ghc-mod has decided that you are using cabal-install instead of stack.

[carymrobbins]

@chris-martin - Any reason you have cabal-install in your stack.yaml? I'm not really sure what that would do on Nix, but it seems odd to try to mix it and stack together, especially since ghc-mod is clearly confused about which one to use.

[DanielG]

@chris-martin You can do stack exec -- ghc-mod --verbose=7 check Foo.hs which should spit out a bunch of helpful information.

I'm pretty sure an old dist/setup-config file lying around. This here is the only code where we call cabal so you should start looking there: https://github.com/DanielG/ghc-mod/blob/master/Language/Haskell/GhcMod/CabalHelper.hs#L166. Another relevant bit is this: https://github.com/DanielG/ghc-mod/blob/master/Language/Haskell/GhcMod/Cradle.hs#L101

I'm starting to think we should disable that code if ghc-mod is executed via stack exec since that does make the user intent quite clear. Can anybody think of a good way to detect if that's the case?

(Also: you really should upgrade to 5.5, lots of bugfixes in there)

[carymrobbins]

It seems that it adds a STACK_EXE env var. Could we assume that we are running in the context of stack exec if that variable is set?

$ stack exec -- printenv | grep -i stack
GHC_PACKAGE_PATH=...
HASKELL_PACKAGE_SANDBOX=...
HASKELL_PACKAGE_SANDBOXES=...
PATH=...
STACK_EXE=/home/crobbins/.local/bin/stack
_=/home/crobbins/.local/bin/stack

[chris-martin]

@carymrobbins I added cabal-install because without it, ghc-mod gives this error:

ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

So I assumed it was necessary.

[chris-martin]

@DanielG There is ./.stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/setup-config. It isn't old - it's created every time I run stack build.

[carymrobbins]

@chris-martin - You were getting that error because ghc-mod thought that you were using cabal to build due to the existence of a dist/setup-config file. I'd get rid of the cabal-install dependency and ensure you don't have any dist/setup-config files anywhere. If you can then rebuild the project with stack, you should be able to try stack exec -- ghc-mod --verbose=7 check Foo.hs as @DanielG suggested.

[chris-martin]

I have gotten rid of the cabal-install dependency and wiped .stack-work. Stack still recreates the setup-config I mentioned above. But even if I subsequently delete that, ghc-mod still tries to invoke cabal.

[chris-martin]

Adding --verbose=7 only adds one additional line of output:

> stack exec -- ghc-mod --verbose=7 check Foo.hs
DEBUG: setup configuration is out of date, reconfiguring Cabal project.
ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

[carymrobbins]

@chris-martin - May be worth jumping on #ghc-mod on freenode to debug this in real time.

[mgsloan]

Here's some of the relevant code (though likely not the root cause): https://github.com/DanielG/ghc-mod/blob/566dbebe298f1e75254a4c3aa07d7410612659d4/Language/Haskell/GhcMod/Cradle.hs#L45

What this means is that if anything goes wrong with ghc-mod's attempt to load your stack project, it'll instead use cabal and not really tell you why. It'd be great if ghc-mod gave informative error message. I don't really follow the logic in the code there, it seems to prefer "cabalCradle" over "sandboxCradle".

[DanielG]

@chris-martin I suggest you upgrade to 5.5 before we do any more debugging. We added another log message for specifically this problem there that should make the problem obvious.

Anyways the setup-config files in .stack-work are completely fine. However if you look in the directory where your stack.yaml file and foo.cabal files are (we call this the "project root directory"), if there's a dist/ directory there that has a setup-config inside that's bad. The path starting from the project root directory has to literally be dist/setup-config any other files of the same name are of no concern for this particular check.

[DanielG]

@carymrobbins STACK_EXE sounds like a good candidate as long as that's something stack only sets and never uses? i.e a user would never ever want to set that in say .profile.

[mgsloan]

@DanielG Yep, STACK_EXE is only set and not checked by stack, so it's quite reasonable to assume that the user wants to use stack when that env var is set.

[chris-martin]

if there's a dist/ directory there that has a setup-config inside that's bad.

Okay, that isn't the problem, then.

[chris-martin]

Switched to lts 5.2 for ghc-mod 5.5:

> stack exec -- ghc-mod --version
ghc-mod version 5.5.0.0 compiled by GHC 7.10.3
> stack exec -- ghc-mod --verbose=7 check src/Foo.hs
DEBUG: setup configuration is out of date
DEBUG: reconfiguring Cabal project
ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

[mgsloan]

I believe ghc-mod requires cabal-install in order to build its cabal-helper auxiliary package.

[chris-martin]

Okay, added haskellPackages.cabal-install back to stack.yaml!

nix:
  enable: true
  packages: [glpk, pcre, zlib,
             haskellPackages.hdevtools,
             haskellPackages.ghc-mod,
             haskellPackages.cabal-install]

> stack exec --no-ghc-package-path -- ghc-mod --verbose=7 check src/Foo.hs
DEBUG: setup configuration is out of date
DEBUG: reconfiguring Cabal project
cabal: At least the following dependencies are missing:
Decimal -any, aeson -any, split -any, text -any, wreq -any
ghc-mod: readCreateProcess: cabal "configure" "--with-ghc=ghc" "--flags" "" (exit 1): failed

[mgsloan]

Well, that's just crazy. Seems like something to report to the ghc-mod tracker, that it's attempting to configure cabal-helper rather than installing it and its deps.

Ideally we'd also have it use stack to install cabal-helper, to avoid the dependency on cabal-install.

[chris-martin]

😓

I'm thinking maybe I'll try to reproduce this in a Docker container later tonight so I can not be the only person in the world who's seen this happen...

[mgsloan]

I think ghc-mod attempts to use your user-local .cabal DB, not sure. Maybe it uses its own temp DB (though, in that case I don't see why this wouldn't always be a problem). So, you should be able to do a "cabal install Decimal aeson split text wreq" to populate that with its deps, as a workaround for now.

Good idea on making a docker container, I'd also appreciate a working ghc-mod setup.

[chris-martin]

@mgsloan Unfortunately that isn't a workaround. On NixOS I have to be using the haskell modules provided by Nix; cabal install will never work.

> stack exec --no-ghc-package-path -- cabal install Decimal aeson split text wreq

[...]

[ 6 of 15] Compiling Network.Wreq.Internal.Lens ( Network/Wreq/Internal/Lens.hs, dist/build/Network/Wreq/Internal/Lens.o )
<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)
cabal: Error: some packages failed to install:
wreq-0.4.1.0 failed during the building phase. The exception was:
ExitFailure 1

[mgsloan]

This mailing list thread seems relevant: https://groups.google.com/forum/#!msg/haskell-stack/_ZBh01VP_fo/0v4SxPw7GwAJ

[DanielG]

@chris-martin a docker image would be lovely actually. I never could get NixOS to work to test ghc-mod with it.

[sergv]

It seems that the problem is that Cabal doesn't like package dbs specified via GHC_PACKAGE_PATH environment variable. Maybe ghc-mod can detect if this variable is set and then pass --package-db flag to cabal so it will understand?

[carymrobbins]

It seems we have a couple more people experiencing this issue - carymrobbins/intellij-haskforce#285

@DanielG - It's odd that ghc-mod is delegating to cabal and not stack. Is there an issue upstream with ghc-mod for this? Should there be?

[mgsloan]

Closing as an upstream issue. Please open specific stack issues as additional tickets.