Closed ruhatch closed 7 years ago
It seems that A) you are running ghc-mod built with ghc 8.0 (lts-7.2 resolver) on a project that seemingly wants 6.19 resolver (ghc 7.10). It won't work this way due to changes in GHC API. you need to build ghc-mod with the same compiler (and usually resolver) as the project. B) you are running via 'stack exec'. This is considered a hack and is deprecated.
Caveat: lts-6.19 has only ghc-mod 5.5. Upgrading to 5.6 (optional, recommended) is kind of a drag (as upgrading any package without changing the resolver is). Be aware of this.
Tl;dr: please check your resolvers. If necessary, run 'stack build ghc-mod' in project directory. If you want ghc-mod 5.6 on ghc 7.10, consult stack manual.
Unfortunately neither of those are true! This project is using resolver lts-7.2 and I installed ghc-mod using stack build ghc-mod
. There is no global ghc-mod, so there is definitely no conflict there. I am not running it using stack exec
, but what makes you think that I was?
Thanks for getting back.
Unfortunately neither of those are true!
I seem to have misread the log output, and got a bit confused about what resolver goes where. See below for a more detailed explanation.
I am not running it using stack exec, but what makes you think that I was?
Basically this line:
Warning: STACK_EXE set, preferring Stack project
This environment variable is usually set by stack exec
, so that's why I assumed that was the case.
Also, you have GHC_PACKAGE_PATH
environment variable set (which is also usually set by stack exec
)
"GHC_PACKAGE_PATH":"/home/rupert/.stack/global-project/.stack-work/install/x86_64-linux/lts-6.19/7.10.3/pkgdb:/home/rupert/.stack/snapshots/x86_64-linux/lts-6.19/7.10.3/pkgdb:/home/rupert/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/package.conf.d","HASKELL_PACKAGE_SANDBOXES":"/home/rupert/.stack/global-project/.stack-work/install/x86_64-linux/lts-6.19/7.10.3/pkgdb:/home/rupert/.stack/snapshots/x86_64-linux/lts-6.19/7.10.3/pkgdb:"
Note that it's pointing to lts-6.19
.
At the same time, ghc-mod is probably installed in
/home/rupert/haskell/music/.stack-work/install/x86_64-linux/lts-7.2/8.0.1/bin:/home/rupert/.stack/snapshots/x86_64-linux/lts-7.2/8.0.1/bin
Note lts-7.2
here.
So yes, I've got those resolvers mixed up a bit (I was answering this while on a train from my phone, so that at least somewhat explains my inadequacy -- again, sorry about that)
But it still seems like you're running Atom via stack exec
, or at least something else sets those environment variables. Not entirely sure what that might be. Definitely not ide-haskell packages -- at the moment it's only responsible for a bit of PATH
manipulation.
I guess check your .bashrc/.bash_profile
(or .zsh*
counterparts, or whatever shell you're using)? Not sure at this point. At the very least, try to unset GHC_PACKAGE_PATH
and run Atom from that environment?
P.S. Note that Atom runs ghc-mod directly, not via stack exec
, so that's why stack exec -- ghc-mod ...
seemingly works. But that is unsupported upstream and can break eventually.
P.P.S. Also just occurred to me, that you might be running your window manager with stack exec
? I mean, you might be using XMonad or something like that, I guess... Graphical applications will usually inherit window manager's environment, so that might be it?.. This is pure speculation at this point, btw, just throwin' some ideas out there, that might help you diagnose. Sorry I can't be of more help.
XMonad!!! facepalm That's some nifty speculation!
I like having XMonad running through stack, but it's not worth the loss of ghc-mod. Do you know of any way to isolate Atom from the changes?
Thank you so much for that revelation, that could have taken a long time to track down!
I just saw this which should make things better! Do you know if it will be merged soon?
I was just about to link you there. I have no idea when or if it will be merged/released, however. +1 it or something while you're at it I guess?
For now, I guess you could unset GHC_PACKAGE_PATH
in XMonad's startupHook
. That will likely break xmonad --recompile
though, so you'll have to change that to stack exec -- xmonad --recompile && stack exec -- xmonad --restart
(I don't remember exact command line used in default M-q
binding, so I might be a little bit off with this suggestion -- use your own judgement).
If you just want this to work with Atom, there's an easier route. You can add the following to your Atom init script (Edit → Init Script...):
delete process.env.GHC_PACKAGE_PATH
This will just unconditionally unset GHC_PACKAGE_PATH
when Atom starts (only for Atom of course). Although there's a caveat that non-stack projects won't work anymore, but that's not an issue for you as far as I can tell?
Thanks again - I am using delete
for now, but I'll keep an eye on the build scripts.
I am running ghc-mod in a Stack project with a local version of ghc-mod installed with
stack build
.When I run
stack exec -- ghc-mod check file
everything works fine, but when Atom invokes ghc-mod I get the following trace:Atom Version: 1.11.2 Electron Version: 1.4.4 System: linux 4.8.2-1-ARCH Thrown From: haskell-ghc-mod package, v1.19.0
Stack Trace
Haskell-ghc-mod: ghc-mod command check failed with error Error
So it seems to be picking up the wrong package.cache for some reason. Any ideas?