using ghc-mod with stack #498

Closed
jbpotonnier opened this Issue Jun 13, 2015 · 60 comments

Comments

Projects
None yet
@jbpotonnier

I'm using ghc-mod through Atom editor (https://github.com/atom-haskell/haskell-ghc-mod)
I tried to make it work using the new stack tool (https://github.com/commercialhaskell/stack)
I could not make ghc-mod work with a stack installation, because it cannot find ghc, or my installed packages.

  • I tried adding --with-ghc option without succes:
» ghc-mod
user error (ghc not found)
  • Then I added ghc to my path, but It did not work. I'm stuck with cabal errors:
» export PATH=$PATH:~/.stack/programs/x86_64-osx/ghc-7.8.4/bin
launching operating system process `cabal configure` failed: cabal configure (exit 1)
cabal: At least the following dependencies are missing:
random-shuffle ==0.0.*, text ==1.2.*

It cannot see some dependencies of my project.

  • Strangely enough, ghc-mod seem to find ghc when I invoke it outside of my project directory
» ghc-mod check incubator/dvorak/Main.hs
incubator/dvorak/Main.hs:14:8:Could not find module ‘System.Random.Shuffle’Use -v to see a list of the files searched for.
incubator/dvorak/Main.hs:13:8:Could not find module ‘Data.Text.Encoding’Use -v to see a list of the files searched for.
incubator/dvorak/Main.hs:12:8:Could not find module ‘Data.Text’Perhaps you meant Data.Set (from containers-0.5.5.1)Use -v to see a list of the files searched for.

You can read the initial stack issue here commercialhaskell/stack#273

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Jun 14, 2015

Owner

As far as I understand stack doesn't use cabal so ghc-mod is pretty much dead in the water and we'd probably need explicit support for stack.

Owner

DanielG commented Jun 14, 2015

As far as I understand stack doesn't use cabal so ghc-mod is pretty much dead in the water and we'd probably need explicit support for stack.

@christetreault christetreault referenced this issue in ucsd-progsys/liquidhaskell Jun 26, 2015

Closed

Look into possibly supporting Stack #407

@vkorablin

This comment has been minimized.

Show comment
Hide comment
@vkorablin

vkorablin Jul 2, 2015

As far as I understand stack doesn't use cabal

That's incorrect--stack is built on cabal.

As far as I understand stack doesn't use cabal

That's incorrect--stack is built on cabal.

@tvh

This comment has been minimized.

Show comment
Hide comment
@tvh

tvh Jul 2, 2015

It does use Cabal the library, yes. It doesn't use cabal-install however. Tahat means there won't be a dist directory needed for that tool to work.

tvh commented Jul 2, 2015

It does use Cabal the library, yes. It doesn't use cabal-install however. Tahat means there won't be a dist directory needed for that tool to work.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Jul 3, 2015

Owner

stack path --dist-dir gives us the directory containing setup-config for some version of Cabal that stack uses. In my current experiment stack seems to install the version of Cabal it's using into the directory returned by stack path --snapshot-pkg-db.

So theoretically we just have to pass that stack dist-dir to cabal-helper and it'll figure out the rest. Unfortunately stack doesn't seem to have a configure command so we'll have to keep using cabal-install to maintain our own setup-config somewhere :/ Unless someone feels like patching stack?

To work around this we can ask stack for the paths to it's package-dbs and pass those down to cabal configure, i.e. cabal configure --package-db=clear --package-db=global --package-db=$(stack path --snapshot-pkg-db) --package-db=$(stack path --local-pkg-db) support for doing this would have to be added to cabal-helper.

One thing I'm still not sure about is how to decide weather to use stack or cabal directly to configure a project if both a cabal and a stack.yml file exist.

Owner

DanielG commented Jul 3, 2015

stack path --dist-dir gives us the directory containing setup-config for some version of Cabal that stack uses. In my current experiment stack seems to install the version of Cabal it's using into the directory returned by stack path --snapshot-pkg-db.

So theoretically we just have to pass that stack dist-dir to cabal-helper and it'll figure out the rest. Unfortunately stack doesn't seem to have a configure command so we'll have to keep using cabal-install to maintain our own setup-config somewhere :/ Unless someone feels like patching stack?

To work around this we can ask stack for the paths to it's package-dbs and pass those down to cabal configure, i.e. cabal configure --package-db=clear --package-db=global --package-db=$(stack path --snapshot-pkg-db) --package-db=$(stack path --local-pkg-db) support for doing this would have to be added to cabal-helper.

One thing I'm still not sure about is how to decide weather to use stack or cabal directly to configure a project if both a cabal and a stack.yml file exist.

@PGGB

This comment has been minimized.

Show comment
Hide comment

PGGB commented Jul 7, 2015

Looks like @ajnsit has started work on it: https://github.com/ajnsit/ghc-mod/tree/stack-support
Here's a reddit thread on it including a workaround script: https://www.reddit.com/r/haskell/comments/3cf5yd/stack_ghcmod_work_in_progress/

@PGGB PGGB referenced this issue in commercialhaskell/stack Jul 7, 2015

Closed

How do I get extra tools #273

@rvion rvion referenced this issue in atom-haskell/ide-haskell Jul 7, 2015

Closed

Stack support #82

@ajnsit

This comment has been minimized.

Show comment
Hide comment
@ajnsit

ajnsit Jul 7, 2015

Even though stack support basically works right now, I just took the path of least resistance in getting it working. So it's quite possible that I'm doing something completely wrong.

From the comments here it seems that cradle is on its way out and cabal-helper is the new way to go. Is that correct? If that's the case then perhaps it makes sense to add first-class support inside cabal-helper for the stack executable, i.e. add it as a separate field to the Programs structure returned by cabal-helper and add special handling everywhere else at par with handling for cabal.

I can start experimenting with getting this working "correctly", with a bit of hand holding.

ajnsit commented Jul 7, 2015

Even though stack support basically works right now, I just took the path of least resistance in getting it working. So it's quite possible that I'm doing something completely wrong.

From the comments here it seems that cradle is on its way out and cabal-helper is the new way to go. Is that correct? If that's the case then perhaps it makes sense to add first-class support inside cabal-helper for the stack executable, i.e. add it as a separate field to the Programs structure returned by cabal-helper and add special handling everywhere else at par with handling for cabal.

I can start experimenting with getting this working "correctly", with a bit of hand holding.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Jul 7, 2015

Owner

cabal-helper doesn't deal with cabal much. The reconfiguration logic is inside ghc-mod. cabal-helper's "only" job is to read a dist/setup-config file and return information about it. So stack executable support should go into ghc-mod.

What you want to be looking at is this: https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/CabalHelper.hs#L113 . That's where the reconfiguration stuff lives. So all we need is a stack configure command or something like that that prepares the setup-config file and then hand off the directory containing that file to cabal-helper and as an added bonus add an option to cabal-helper to specify a package-db where it should look for the Cabal library that wrote that setup-config file since otherwise it'll try to install the appropriate version itself which is unnecessary as stack seems to handle that.

Owner

DanielG commented Jul 7, 2015

cabal-helper doesn't deal with cabal much. The reconfiguration logic is inside ghc-mod. cabal-helper's "only" job is to read a dist/setup-config file and return information about it. So stack executable support should go into ghc-mod.

What you want to be looking at is this: https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/CabalHelper.hs#L113 . That's where the reconfiguration stuff lives. So all we need is a stack configure command or something like that that prepares the setup-config file and then hand off the directory containing that file to cabal-helper and as an added bonus add an option to cabal-helper to specify a package-db where it should look for the Cabal library that wrote that setup-config file since otherwise it'll try to install the appropriate version itself which is unnecessary as stack seems to handle that.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Jul 7, 2015

Owner

@ajnsit if you would submit a WIP pull request we can do some more thorough reviewing. I'll be at a festival until Sa. though so I'll only be able to look at it after that.

Owner

DanielG commented Jul 7, 2015

@ajnsit if you would submit a WIP pull request we can do some more thorough reviewing. I'll be at a festival until Sa. though so I'll only be able to look at it after that.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Jul 7, 2015

Owner

Also beware of this issue: #505

Owner

DanielG commented Jul 7, 2015

Also beware of this issue: #505

@ajnsit

This comment has been minimized.

Show comment
Hide comment
@ajnsit

ajnsit Jul 8, 2015

Thanks for the pointers! I'll submit a WIP pull request with the code I have now, and start looking at the things you mentioned.

ajnsit commented Jul 8, 2015

Thanks for the pointers! I'll submit a WIP pull request with the code I have now, and start looking at the things you mentioned.

@xavier83

This comment has been minimized.

Show comment
Hide comment
@xavier83

xavier83 Jul 25, 2015

any update?

any update?

@joehealy

This comment has been minimized.

Show comment
Hide comment
@joehealy

joehealy Aug 10, 2015

See #508 for the in progress pull request

See #508 for the in progress pull request

@cies

This comment has been minimized.

Show comment
Hide comment
@cies

cies Aug 19, 2015

Now see #549 for the latest and greatest PR.

cies commented Aug 19, 2015

Now see #549 for the latest and greatest PR.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 19, 2015

Owner

Actually the latest and greatest is on this branch: https://github.com/kazu-yamamoto/ghc-mod/tree/stack-support

Owner

DanielG commented Aug 19, 2015

Actually the latest and greatest is on this branch: https://github.com/kazu-yamamoto/ghc-mod/tree/stack-support

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 20, 2015

Owner

Scratch that it's in master now. Everybody test this cause it's going in the next release.

Owner

DanielG commented Aug 20, 2015

Scratch that it's in master now. Everybody test this cause it's going in the next release.

@bixuanzju

This comment has been minimized.

Show comment
Hide comment
@bixuanzju

bixuanzju Aug 20, 2015

@DanielG Hi, first thank you for the stack support.

Is there anything special to do before use ghc-mod with stack? I asked because I tried to use the latest ghc-mod in my project, and it gives this error message

cabal-helper-wrapper: ghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
ghc-mod: readProcessStderrChan: /Users/jeremybi/.cabal/libexec/cabal-helper-wrapper "/Users/jeremybi/fcore" "/Users/jeremybi/fcore/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0" (exit 1)

Any pointers would be appreciated.

@DanielG Hi, first thank you for the stack support.

Is there anything special to do before use ghc-mod with stack? I asked because I tried to use the latest ghc-mod in my project, and it gives this error message

cabal-helper-wrapper: ghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
ghc-mod: readProcessStderrChan: /Users/jeremybi/.cabal/libexec/cabal-helper-wrapper "/Users/jeremybi/fcore" "/Users/jeremybi/fcore/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0" (exit 1)

Any pointers would be appreciated.

@PierreR

This comment has been minimized.

Show comment
Hide comment
@PierreR

PierreR Aug 20, 2015

Contributor

I see the same error as @bixuanzju within emacs.

There is another problem. ghc-mod check work fine the first time but if I add a dep to the project, then even after a stack build, it won't find the new dep lib.
For instance

> stack build

> ghc-mod check src/Main.hs
src/Main.hs:4:8:Could not find module ‘Pipes’It is a member of the hidden package ‘pipes-4.1.6@pipes_E83Gh9X08vG1gU7tlpfBH7’.Perhaps you need to add ‘pipes’ to the build-depends in your .cabal file.Use -v to see a list of the files searched for.

I need to recompile ghc-mod to make it work again which is really weird ...

Contributor

PierreR commented Aug 20, 2015

I see the same error as @bixuanzju within emacs.

There is another problem. ghc-mod check work fine the first time but if I add a dep to the project, then even after a stack build, it won't find the new dep lib.
For instance

> stack build

> ghc-mod check src/Main.hs
src/Main.hs:4:8:Could not find module ‘Pipes’It is a member of the hidden package ‘pipes-4.1.6@pipes_E83Gh9X08vG1gU7tlpfBH7’.Perhaps you need to add ‘pipes’ to the build-depends in your .cabal file.Use -v to see a list of the files searched for.

I need to recompile ghc-mod to make it work again which is really weird ...

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 21, 2015

Owner

@bixuanzju You might have botched up your installation. Don't move the ghc-mod executable around and remove the original installation directory, tell cabal via --prefix=PATH where you want it to install ghc-mod to. The problem is that cabal-helper installs it's wrapper executable in $libexec and that path has to be hardcoded in the cabal-helper library for that to work so you can't move the installation prefix after you compiled it.

Since it seems to be looking in /Users/jeremybi/.cabal/libexec/cabal-helper-wrapper i suppose you can just do a cabal install cabal-helper and that might fix it.

Owner

DanielG commented Aug 21, 2015

@bixuanzju You might have botched up your installation. Don't move the ghc-mod executable around and remove the original installation directory, tell cabal via --prefix=PATH where you want it to install ghc-mod to. The problem is that cabal-helper installs it's wrapper executable in $libexec and that path has to be hardcoded in the cabal-helper library for that to work so you can't move the installation prefix after you compiled it.

Since it seems to be looking in /Users/jeremybi/.cabal/libexec/cabal-helper-wrapper i suppose you can just do a cabal install cabal-helper and that might fix it.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 21, 2015

Owner

@PierreR now that problem is somewhat strange I'll see if I can reproduce that later

Owner

DanielG commented Aug 21, 2015

@PierreR now that problem is somewhat strange I'll see if I can reproduce that later

@bixuanzju

This comment has been minimized.

Show comment
Hide comment
@bixuanzju

bixuanzju Aug 21, 2015

@DanielG I cloned ghc-mod and do stack install inside it, and the executables reside in ~/.local/bin/. So you are saying I need to use cabal to install ghc-mod?

@DanielG I cloned ghc-mod and do stack install inside it, and the executables reside in ~/.local/bin/. So you are saying I need to use cabal to install ghc-mod?

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 21, 2015

Owner

Ah, I see. That might be a stack issue then. So did you configure stack to put executables into .local/bin or how did they end up there? Usually it install stuff into .cabal, doesn't it?

Owner

DanielG commented Aug 21, 2015

Ah, I see. That might be a stack issue then. So did you configure stack to put executables into .local/bin or how did they end up there? Usually it install stuff into .cabal, doesn't it?

@bixuanzju

This comment has been minimized.

Show comment
Hide comment
@bixuanzju

bixuanzju Aug 21, 2015

No, I didn't. This is where stack put executables by default I think. stack install is an alias of stack build --copy-bins, which will copy binaries to the local-bin-path (~/.local/bin by default). I can configure local-bin-path to point to ~/.cabal if needed.

No, I didn't. This is where stack put executables by default I think. stack install is an alias of stack build --copy-bins, which will copy binaries to the local-bin-path (~/.local/bin by default). I can configure local-bin-path to point to ~/.cabal if needed.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 21, 2015

Owner

Okay I have no idea how the stack guys could thing this is a good idea but whatever. (reported over here: commercialhaskell/stack#828) So long as you don't move/remove anything out of the original installation prefix it should still work. Alternatively just use cabal install for now.

Owner

DanielG commented Aug 21, 2015

Okay I have no idea how the stack guys could thing this is a good idea but whatever. (reported over here: commercialhaskell/stack#828) So long as you don't move/remove anything out of the original installation prefix it should still work. Alternatively just use cabal install for now.

@xavier83

This comment has been minimized.

Show comment
Hide comment
@xavier83

xavier83 Aug 21, 2015

I can't find stack.yaml

I can't find stack.yaml

@cies

This comment has been minimized.

Show comment
Hide comment

@lierdakil lierdakil referenced this issue in atom-haskell/haskell-ghc-mod Aug 24, 2015

Closed

haskell-ghc-mod doesn't support local GHC using Stack #44

@carymrobbins carymrobbins referenced this issue in carymrobbins/intellij-haskforce Aug 25, 2015

Closed

Possibility to use stack instead of cabal #167

@DanielG DanielG added this to the v5.3.1.0 milestone Aug 28, 2015

@WillSewell

This comment has been minimized.

Show comment
Hide comment
@WillSewell

WillSewell Aug 30, 2015

I'm still not sure on how to use the new version. I've installed the code form master, and run ghc-mod check [FILE] in my stack project, but it still says cabal: At least the following dependencies are missing: .... My understanding was that the new code in master was meant to have fixed this? Is this not the case, or am I doing something wrong?

Thanks for your work on this! It's really appreciated.

I'm still not sure on how to use the new version. I've installed the code form master, and run ghc-mod check [FILE] in my stack project, but it still says cabal: At least the following dependencies are missing: .... My understanding was that the new code in master was meant to have fixed this? Is this not the case, or am I doing something wrong?

Thanks for your work on this! It's really appreciated.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Aug 31, 2015

Owner

@WillSewell Run cabal clean first or rm -r dist/ otherwise ghc-mod will default to using cabal.

Owner

DanielG commented Aug 31, 2015

@WillSewell Run cabal clean first or rm -r dist/ otherwise ghc-mod will default to using cabal.

@isomarcte

This comment has been minimized.

Show comment
Hide comment
@isomarcte

isomarcte Aug 31, 2015

I am still having issues with the latest master build (commit hash e23e68279321e719b273f90fb1b7f6aed10cc534).
Here is how to reproduce the issue,

  1. Setup a simple "Hello World" project with stack

    $ stack new helloworld simple
    
  2. Build the project.

    $ cd helloworld
    $ stack build
    
  3. Open helloworld/src/Main.hs in emacs and you will get the following error

    Warning: Stack project configuration is out of date, please reconfigure manually
             using 'stack build'
    Warning: Stack project configuration is out of date, please reconfigure manually
             using 'stack build'
    cabal-helper-wrapper: Failed to grab lock ("/home/foo/.stack/lockfile"); other stack instance running.  Waiting.../setup-config: canonicalizePath: does not exist (No such file or directory)
    ghc-mod: readCreateProcess: /home/foo/.cabal/libexec/cabal-helper-wrapper "/home/foo/git/helloworld" "Failed to grab lock (\"/home/foo/.stack/lockfile\"); other stack instance running.  Waiting..." "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" (exit 1): failed
    
  4. Besides the error, this also creates and does not clean up a lockfile in ~/.stack/. Even though there are no running stack, ghc, ghci, or cabal processes.

By the way, is this kind of thing still supposed to go on this issue or should I be opening new issues?

I am still having issues with the latest master build (commit hash e23e68279321e719b273f90fb1b7f6aed10cc534).
Here is how to reproduce the issue,

  1. Setup a simple "Hello World" project with stack

    $ stack new helloworld simple
    
  2. Build the project.

    $ cd helloworld
    $ stack build
    
  3. Open helloworld/src/Main.hs in emacs and you will get the following error

    Warning: Stack project configuration is out of date, please reconfigure manually
             using 'stack build'
    Warning: Stack project configuration is out of date, please reconfigure manually
             using 'stack build'
    cabal-helper-wrapper: Failed to grab lock ("/home/foo/.stack/lockfile"); other stack instance running.  Waiting.../setup-config: canonicalizePath: does not exist (No such file or directory)
    ghc-mod: readCreateProcess: /home/foo/.cabal/libexec/cabal-helper-wrapper "/home/foo/git/helloworld" "Failed to grab lock (\"/home/foo/.stack/lockfile\"); other stack instance running.  Waiting..." "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" (exit 1): failed
    
  4. Besides the error, this also creates and does not clean up a lockfile in ~/.stack/. Even though there are no running stack, ghc, ghci, or cabal processes.

By the way, is this kind of thing still supposed to go on this issue or should I be opening new issues?

@WillSewell

This comment has been minimized.

Show comment
Hide comment
@WillSewell

WillSewell Aug 31, 2015

@DanielG, thank you. That worked great.

I have a new issue though. When I try and check a file I get:

Warning: Stack project configuration is out of date, please reconfigure manually
         using 'stack build'
cabal-helper-wrapper: dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/setup-config: canonicalizePath: does not exist (No such file or directory)
ghc-mod: readCreateProcess: /Users/will/.cabal/libexec/cabal-helper-wrapper "/Users/will/src/megabus" "dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/" "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" (exit 1): failed

Even though the file .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/setup-config exists.

@DanielG, thank you. That worked great.

I have a new issue though. When I try and check a file I get:

Warning: Stack project configuration is out of date, please reconfigure manually
         using 'stack build'
cabal-helper-wrapper: dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/setup-config: canonicalizePath: does not exist (No such file or directory)
ghc-mod: readCreateProcess: /Users/will/.cabal/libexec/cabal-helper-wrapper "/Users/will/src/megabus" "dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/" "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" (exit 1): failed

Even though the file .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/setup-config exists.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 1, 2015

Owner

"dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/", notice the dist-dir: prefix. Something must've gone wrong while parsing stack's output.

Owner

DanielG commented Sep 1, 2015

"dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/", notice the dist-dir: prefix. Something must've gone wrong while parsing stack's output.

@WillSewell

This comment has been minimized.

Show comment
Hide comment
@WillSewell

WillSewell Sep 1, 2015

Oh I see. The way it is printed is quite confusing. So is this a bug in ghc-mod? When I run stack path --dist-dir I get dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/ which is the correct path.

Oh I see. The way it is printed is quite confusing. So is this a bug in ghc-mod? When I run stack path --dist-dir I get dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/ which is the correct path.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 2, 2015

Owner

@WillSewell You must be using an old version of stack or something, mine just prints the path without the prefix.

Owner

DanielG commented Sep 2, 2015

@WillSewell You must be using an old version of stack or something, mine just prints the path without the prefix.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 2, 2015

Owner

Anyways stack support is conceptually ready on the master branch now. You need at least stack-0.1.4.0 for it to work, i.e. build stack from master for now. So everybody test test test and we can have ourselves a release soon.

Owner

DanielG commented Sep 2, 2015

Anyways stack support is conceptually ready on the master branch now. You need at least stack-0.1.4.0 for it to work, i.e. build stack from master for now. So everybody test test test and we can have ourselves a release soon.

@WillSewell

This comment has been minimized.

Show comment
Hide comment
@WillSewell

WillSewell Sep 2, 2015

@DanielG OK thanks. I just tried the following:

  1. Checkout stack master branch, run stack build
  2. Use the built version of stack to build the latest ghc-mod master branch
  3. stack setup and stack build my own project using the newly built version of stack
  4. When I run ghc-mod check on a file in my own project with the newly built version, I get:
Warning: Stack project configuration is out of date, please reconfigure manually
         using 'stack build' as your stack version is too old (need at least 0.1.4.0)
cabal-helper-wrapper: Caching build plan/setup-config: canonicalizePath: does not exist (No such file or directory)
ghc-mod: readCreateProcess: /Users/will/src/ghc-mod/.stack-work/install/x86_64-osx/lts-3.1/7.10.2/libexec/cabal-helper-wrapper "/Users/will/src/megabus" "Caching build plan" "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=/Users/will/.stack/programs/x86_64-osx/ghc-7.10.2/bin/ghc" "--with-ghc-pkg=/Users/will/.stack/programs/x86_64-osx/ghc-7.10.2/bin/ghc-pkg" "--with-cabal=cabal" (exit 1): failed

@DanielG OK thanks. I just tried the following:

  1. Checkout stack master branch, run stack build
  2. Use the built version of stack to build the latest ghc-mod master branch
  3. stack setup and stack build my own project using the newly built version of stack
  4. When I run ghc-mod check on a file in my own project with the newly built version, I get:
Warning: Stack project configuration is out of date, please reconfigure manually
         using 'stack build' as your stack version is too old (need at least 0.1.4.0)
cabal-helper-wrapper: Caching build plan/setup-config: canonicalizePath: does not exist (No such file or directory)
ghc-mod: readCreateProcess: /Users/will/src/ghc-mod/.stack-work/install/x86_64-osx/lts-3.1/7.10.2/libexec/cabal-helper-wrapper "/Users/will/src/megabus" "Caching build plan" "package-db-stack" "entrypoints" "source-dirs" "ghc-options" "ghc-src-options" "ghc-pkg-options" "ghc-merged-pkg-options" "ghc-lang-options" "--with-ghc=/Users/will/.stack/programs/x86_64-osx/ghc-7.10.2/bin/ghc" "--with-ghc-pkg=/Users/will/.stack/programs/x86_64-osx/ghc-7.10.2/bin/ghc-pkg" "--with-cabal=cabal" (exit 1): failed
@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Sep 2, 2015

Contributor

I also had trouble using ghc-mod with stack via Emacshaskell-mode.ghc-modtries to runcabal configure`, and obviously that doesn't work any more, because the sandboxes with several local dependencies aren't known to plain Cabal.

Contributor

peti commented Sep 2, 2015

I also had trouble using ghc-mod with stack via Emacshaskell-mode.ghc-modtries to runcabal configure`, and obviously that doesn't work any more, because the sandboxes with several local dependencies aren't known to plain Cabal.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 2, 2015

Owner

@peti did you do this: #498 (comment) ?

Owner

DanielG commented Sep 2, 2015

@peti did you do this: #498 (comment) ?

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Sep 2, 2015

Contributor

I though that I tried this in a fresh copy, yes, but now I'm not sure anymore. I'll give it another try.

Contributor

peti commented Sep 2, 2015

I though that I tried this in a fresh copy, yes, but now I'm not sure anymore. I'll give it another try.

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Sep 2, 2015

Contributor
$ stack build

$ rm -rf dist

$ ghc-mod debug
cabal: At least the following dependencies are missing:
distribution-nixpkgs -any, language-nix -any
ghc-mod: readCreateProcess: cabal "configure" "--with-ghc=ghc" (exit 1): failed
Contributor

peti commented Sep 2, 2015

$ stack build

$ rm -rf dist

$ ghc-mod debug
cabal: At least the following dependencies are missing:
distribution-nixpkgs -any, language-nix -any
ghc-mod: readCreateProcess: cabal "configure" "--with-ghc=ghc" (exit 1): failed
@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 2, 2015

Owner

And you have a stack.yaml file in the same directory as the cabal file? (IIRC stack also supports project collections? which we don't yet)

Owner

DanielG commented Sep 2, 2015

And you have a stack.yaml file in the same directory as the cabal file? (IIRC stack also supports project collections? which we don't yet)

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 2, 2015

Owner

Maybe it's this line mzero'ing out https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/Cradle.hs#L92 mind adding a few traces around there to find out when it's jumping out of that function?

Owner

DanielG commented Sep 2, 2015

Maybe it's this line mzero'ing out https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/Cradle.hs#L92 mind adding a few traces around there to find out when it's jumping out of that function?

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Sep 2, 2015

Contributor

No, I have a stack.yml file in the directory one level above that ties 4 separate libraries together. I suppose that is the problem then. Sorry for adding to the noise; I didn't realize that conglomerate repositories weren't supported.

Contributor

peti commented Sep 2, 2015

No, I have a stack.yml file in the directory one level above that ties 4 separate libraries together. I suppose that is the problem then. Sorry for adding to the noise; I didn't realize that conglomerate repositories weren't supported.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 2, 2015

Owner

I just don't know how they are supposed to work, it should be pretty easy to add at this point though if you want to give it a shot.

Owner

DanielG commented Sep 2, 2015

I just don't know how they are supposed to work, it should be pretty easy to add at this point though if you want to give it a shot.

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Sep 2, 2015

Contributor

I'd love to, but the truth is that I won't be able to spend time working on that issue. We're crazy busy compiling the 15.09 release of NixOS. Optimizing the IDE environment is a bit of a secondary task under those conditions. I may have time to come back to this in a few weeks, maybe, but I can't promise anything. I'll be perfectly happy if someone else beats me to it. :-)

Contributor

peti commented Sep 2, 2015

I'd love to, but the truth is that I won't be able to spend time working on that issue. We're crazy busy compiling the 15.09 release of NixOS. Optimizing the IDE environment is a bit of a secondary task under those conditions. I may have time to come back to this in a few weeks, maybe, but I can't promise anything. I'll be perfectly happy if someone else beats me to it. :-)

@z0isch

This comment has been minimized.

Show comment
Hide comment
@z0isch

z0isch Sep 2, 2015

I'm running Windows and having a different problem than I see in this issue. I have a stack.yaml file in the same directory as my .cabal file and I have done the cabal clean command. Here's the output from running ghc-mod check on a file in my project:

cabal: ghc-pkg.exe: Data.Binary.Get.runGet at position 410744: demandInput: not enough bytes
ghc-mod.exe: readProcess: cabal "configure" "--with-ghc=ghc" "--package-db=clear" "--package-db=global" "--package-db=C:\\Users\\aruf.BELLARMINE\\AppData\\Roaming\\stack\\snapshots\\i386-windows\\lts-3.3\\7.10.2\\pkgdb" "--package-db=C:\\Users\\aruf.BELLARMINE\\Desktop\\servant-test\\.stack-work\\install\\i386-windows\\lts-3.3\\7.10.2\\pkgdb" (exit 1): failed

z0isch commented Sep 2, 2015

I'm running Windows and having a different problem than I see in this issue. I have a stack.yaml file in the same directory as my .cabal file and I have done the cabal clean command. Here's the output from running ghc-mod check on a file in my project:

cabal: ghc-pkg.exe: Data.Binary.Get.runGet at position 410744: demandInput: not enough bytes
ghc-mod.exe: readProcess: cabal "configure" "--with-ghc=ghc" "--package-db=clear" "--package-db=global" "--package-db=C:\\Users\\aruf.BELLARMINE\\AppData\\Roaming\\stack\\snapshots\\i386-windows\\lts-3.3\\7.10.2\\pkgdb" "--package-db=C:\\Users\\aruf.BELLARMINE\\Desktop\\servant-test\\.stack-work\\install\\i386-windows\\lts-3.3\\7.10.2\\pkgdb" (exit 1): failed
@WillSewell

This comment has been minimized.

Show comment
Hide comment
@WillSewell

WillSewell Sep 4, 2015

Hey @DanielG, do you have any idea how I can start investigating the issue I'm having? #498 (comment) Thanks

Hey @DanielG, do you have any idea how I can start investigating the issue I'm having? #498 (comment) Thanks

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 4, 2015

Owner

@z0isch you need stack master you're probably running into the path seperator problem. ghc on your PATH is most likely a different one from the one stack is using.

Owner

DanielG commented Sep 4, 2015

@z0isch you need stack master you're probably running into the path seperator problem. ghc on your PATH is most likely a different one from the one stack is using.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 4, 2015

Owner

@WillSewell Stack is writing something to stdout that it shouldn't, find out how to reproduce this and I can go report a bug with them.

Owner

DanielG commented Sep 4, 2015

@WillSewell Stack is writing something to stdout that it shouldn't, find out how to reproduce this and I can go report a bug with them.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 4, 2015

Owner

It's must be happening when running stack path, stack build --only-dependencies or stack build --only-configure.

Owner

DanielG commented Sep 4, 2015

It's must be happening when running stack path, stack build --only-dependencies or stack build --only-configure.

@z0isch

This comment has been minimized.

Show comment
Hide comment
@z0isch

z0isch Sep 4, 2015

@DanielG just updated to stack master and it looks like it is using the correct ghc version now. I am hitting another error when running a ghc-mod check

ghc-mod.exe: While parsing "C:\\Users\\aruf.BELLARMINE\\AppData\\Roaming\\stack\\snapshots\\i386-windows\\lts-3.3\\7.10.2\\pkgdb\\package.cache": demandInput: not enough bytes

z0isch commented Sep 4, 2015

@DanielG just updated to stack master and it looks like it is using the correct ghc version now. I am hitting another error when running a ghc-mod check

ghc-mod.exe: While parsing "C:\\Users\\aruf.BELLARMINE\\AppData\\Roaming\\stack\\snapshots\\i386-windows\\lts-3.3\\7.10.2\\pkgdb\\package.cache": demandInput: not enough bytes
@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 5, 2015

Owner

It sounds like it's using the wrong ghc-pkg version but I don't know why :/

Owner

DanielG commented Sep 5, 2015

It sounds like it's using the wrong ghc-pkg version but I don't know why :/

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 7, 2015

Owner

@z0isch the ghc version you compiled ghc-mod with is different from the one used by your stack project, recompile ghc-mod with the right version.

Owner

DanielG commented Sep 7, 2015

@z0isch the ghc version you compiled ghc-mod with is different from the one used by your stack project, recompile ghc-mod with the right version.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 7, 2015

Owner

@peti multi package stack project should work now.

Owner

DanielG commented Sep 7, 2015

@peti multi package stack project should work now.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 7, 2015

Owner

Stack support landed in master, so closing.

Owner

DanielG commented Sep 7, 2015

Stack support landed in master, so closing.

@DanielG DanielG closed this Sep 7, 2015

@boj boj referenced this issue in syl20bnr/spacemacs Sep 8, 2015

Closed

[Haskell] stack only setup #2142

@peti

This comment has been minimized.

Show comment
Hide comment
@peti

peti Sep 30, 2015

Contributor

Is this code included in the 5.4.0.0 release? I'm asking because I tried to use ghc-mod again in a conglomerate repository, and when compiling a library that had internal dependencies within the Stack repo it (cabal-helper) didn't know how to find them, so ghc-mod didn't work for me.

Contributor

peti commented Sep 30, 2015

Is this code included in the 5.4.0.0 release? I'm asking because I tried to use ghc-mod again in a conglomerate repository, and when compiling a library that had internal dependencies within the Stack repo it (cabal-helper) didn't know how to find them, so ghc-mod didn't work for me.

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Sep 30, 2015

Owner

@peti https://github.com/kazu-yamamoto/ghc-mod/wiki#its-not-working

If it's not that open another issue about it please.

Owner

DanielG commented Sep 30, 2015

@peti https://github.com/kazu-yamamoto/ghc-mod/wiki#its-not-working

If it's not that open another issue about it please.

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Oct 4, 2015

Contributor

ghc-mod bakes in the path of the libraries of the compiler used to build it. could that be the cause ?
sounds like an indeterminacy opportunity

ghc-mod debug

built with my system wide gcc :

 GHC System libraries: /Users/nrolland/.nix-profile/lib/ghc-7.10.2

built with stack :

GHC System libraries: /Users/nrolland/.stack/programs/x86_64-osx/ghc-7.10.2/lib/ghc-7.10.2
Contributor

nrolland commented Oct 4, 2015

ghc-mod bakes in the path of the libraries of the compiler used to build it. could that be the cause ?
sounds like an indeterminacy opportunity

ghc-mod debug

built with my system wide gcc :

 GHC System libraries: /Users/nrolland/.nix-profile/lib/ghc-7.10.2

built with stack :

GHC System libraries: /Users/nrolland/.stack/programs/x86_64-osx/ghc-7.10.2/lib/ghc-7.10.2
@deflexor

This comment has been minimized.

Show comment
Hide comment
@deflexor

deflexor Oct 17, 2015

Just did fresh install of stack, then haskell via stack setup, then configured emacs as described here: https://github.com/serras/emacs-haskell-tutorial/blob/master/tutorial.md

Then after starting emacs and opening .hs file got this error message:

cabal-helper-wrapper: ghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
ghc-mod: GMEProcess "readProcessStderrChan" "/home/deflexor/.stack/global/.stack-work/install/x86_64-linux/lts-3.9/7.10.2/libexec/cabal-helper-wrapper" ["/tmp/hhi","/tmp/hhi/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0"] (Left 1)
cabal-helper-wrapper: ghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
ghc-mod: GMEProcess "readProcessStderrChan" "/home/deflexor/.stack/global/.stack-work/install/x86_64-linux/lts-3.9/7.10.2/libexec/cabal-helper-wrapper" ["/tmp/hhi","/tmp/hhi/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0"] (Left 1)

And there is no dist subdirectory in project dir.

Just did fresh install of stack, then haskell via stack setup, then configured emacs as described here: https://github.com/serras/emacs-haskell-tutorial/blob/master/tutorial.md

Then after starting emacs and opening .hs file got this error message:

cabal-helper-wrapper: ghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
ghc-mod: GMEProcess "readProcessStderrChan" "/home/deflexor/.stack/global/.stack-work/install/x86_64-linux/lts-3.9/7.10.2/libexec/cabal-helper-wrapper" ["/tmp/hhi","/tmp/hhi/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0"] (Left 1)
cabal-helper-wrapper: ghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
ghc-mod: GMEProcess "readProcessStderrChan" "/home/deflexor/.stack/global/.stack-work/install/x86_64-linux/lts-3.9/7.10.2/libexec/cabal-helper-wrapper" ["/tmp/hhi","/tmp/hhi/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0"] (Left 1)

And there is no dist subdirectory in project dir.

@nrolland

This comment has been minimized.

Show comment
Hide comment
@nrolland

nrolland Oct 17, 2015

Contributor

@deflexor which version if GHC did you compile with ? which version of GHC this project targets + is installed ?

Contributor

nrolland commented Oct 17, 2015

@deflexor which version if GHC did you compile with ? which version of GHC this project targets + is installed ?

@deflexor

This comment has been minimized.

Show comment
Hide comment
@deflexor

deflexor Oct 18, 2015

GHC, version 7.10.2

GHC, version 7.10.2

@DanielG

This comment has been minimized.

Show comment
Hide comment
@DanielG

DanielG Oct 18, 2015

Owner

@nrolland @deflexor please don't hijak closed issues and open a new one instead. It's hard enough to keep track of ghc-mod's issues without closed issues still being active with unrelated discussions, thanks.

Owner

DanielG commented Oct 18, 2015

@nrolland @deflexor please don't hijak closed issues and open a new one instead. It's hard enough to keep track of ghc-mod's issues without closed issues still being active with unrelated discussions, thanks.

Repository owner locked and limited conversation to collaborators Oct 18, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.