Different behavior between launch stack exec hie and hie directly

[JPMoresmau]

via stack:

jpmoresmau:~/Documents/haskell-ide-engine$ stack exec hie
{"cmd":"ghcmod:type","params":{"file":{"file":"/home/jpmoresmau/Documents/haskell-ide-engine/src/Haskell/Ide/Engine/Types.hs"},"start_pos":{"pos":[21,9]}}}
^B
{"type_info":"21 5 21 17 \"TChan ChannelResponse\"\n21 5 21 17 \"ChannelRequest -> TChan ChannelResponse\"\n21 5 21 17 \"ChannelRequest\"\n21 5 21 17 \"TChan ChannelResponse\"\n"}

This seems ok.
Via the executable directly:

jpmoresmau:~/Documents/haskell-ide-engine$ .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/hie/hie
{"cmd":"ghcmod:type","params":{"file":{"file":"/home/jpmoresmau/Documents/haskell-ide-engine/src/Haskell/Ide/Engine/Types.hs"},"start_pos":{"pos":[21,9]}}}
^B
EXCEPTION: types:
       Could not find module ‘Data.Aeson’
       Perhaps you meant Data.Version (from base-4.8.1.0)
       Use -v to see a list of the files searched for.
       Could not find module ‘Control.Concurrent.STM.TChan’
       Perhaps you meant
         Control.Concurrent.Chan (from base-4.8.1.0)
         Control.Concurrent.MVar (from base-4.8.1.0)
       Use -v to see a list of the files searched for.
       Could not find module ‘Haskell.Ide.Engine.PluginDescriptor’
       Use -v to see a list of the files searched for.
{"type_info":""}

What does stack exec do that calling the executable directly doesn't do? Surely calling the executable directly should also work.

[alanz]

Is this against master?

[JPMoresmau]

Yep

[alanz]

Ok, will have a look. Have been tied up this weekend

[cocreature]

I can reproduce this. Interestingly enough it also crashes for me when I don’t use stack exec because it still can’t find the PluginDescriptor module, but in that case it finds Data.Aeson.

This exception seems to be thrown by the ghc-mod plugin. stack exec sets some paths, so I suppose that causes ghc-mod to find them the module when used inside of stack exec.

[alanz]

I know ghc-mod and stack are not always friends at the moment at runtime,
in terms of access to packages.

On Sun, Nov 22, 2015 at 7:35 PM, Moritz Kiefer notifications@github.com
wrote:

I can reproduce this. Interestingly enough it also crashes for me when I
don’t use stack exec because it still can’t find the PluginDescriptor
module, but in that case it finds Data.Aeson.

This exception seems to be thrown by the ghc-mod plugin. stack exec sets
some paths, so I suppose that causes ghc-mod to find them the module when
used inside of stack exec.

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

[alanz]

This may be pointing to a potential problem lying ahead, namely making sure the compiler, project and tools all agree on the versions of things to use.

[DanielG]

Are you running ghc-mod as an executable now or using the library?

[alanz]

Library

[JPMoresmau]

It's just a question of GHC_PACKAGE_PATH. If I set it as the value that stack uses, then things work. Of course, this begs the question, how should we handle this? Should the client IDE pass that value? Should we try to gather it ourselves from the path of the project (using .cabal-sandbox or stack.yml)

[cocreature]

Imho we should figure that out ourselves. This is something every IDE needs so leaving it up to the IDE only results in a lot of different implementations of the same thing.

[alanz]

Agree, but it may depend on the O/S as well as what environment the
specific project is running in.

In general I would expect hie to be installed as a dev-machine level tool,
rather than an individual project tool.

So running it inside its own .stack-work may be an unusual/dev-only
situation

On Sun, Nov 22, 2015 at 11:14 PM, Moritz Kiefer notifications@github.com
wrote:

Imho we should figure that out ourselves. This is something every IDE
needs so leaving it up to the IDE only results in a lot of different
implementations of the same thing.

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

[JPMoresmau]

So the status: ghc-mod requires the working directory to be the root directory of the project, period. You can run runGhcModT' and pass it a directory, but ghc-mod will throw an error if the working directory doesn't match the project root directory anyway. Which is why the current tests pass (ghc-mod finds a stack file and cabal file in the current directory, our own root directory), but calling the executable from anywhere else will fail, since we set the working directory to be the user home directory. So we basically have to call ghc-mod rootInfo function to get the working directory to use. Working on it.

[alanz]

Thanks.

We need this functionality, to be able to work on different projects within
an IDE anyway.

On Mon, Nov 23, 2015 at 1:03 AM, JP Moresmau notifications@github.com
wrote:

So the status: ghc-mod requires the working directory to be the root
directory of the project, period. You can run runGhcModT' and pass it a
directory, but ghc-mod will throw an error if the working directory doesn't
match the project root directory anyway. Which is why the current tests
pass (ghc-mod finds a stack file and cabal file in the current directory,
our own root directory), but calling the executable from anywhere else will
fail, since we set the working directory to be the user home directory. So
we basically have to call ghc-mod rootInfo function to get the working
directory to use. Working on it.

—
Reply to this email directly or view it on GitHub
#87 (comment)
.