stack project in sub-directory

[jeapostrophe]

I have a project that I'm opening in VSCode. The Haskell code is in a sub-directory, ./hs.

Without a hie.yaml, when the VSCode extension tries to get the cradle, it runs

⫸ ~/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-0.3.0-darwin --project-ghc-version
Module "./reach-lang/a" is loaded by Cradle: Cradle {cradleRootDir = "./reach-lang", cradleOptsProg = CradleAction: Default}
Cradle requires ghc but couldn't find it
Cradle {cradleRootDir = "./reach-lang", cradleOptsProg = CradleAction: Default}

But, when I run that from the hs directory, I get:

⫸ ~/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-0.3.0-darwin --project-ghc-version
Found "./reach-lang/hs/hie.yaml" for "./reach-lang/hs/a"
Module "./reach-lang/hs/a" is loaded by Cradle: Cradle {cradleRootDir = "./reach-lang/hs", cradleOptsProg = CradleAction: Stack}
8.8.4

So, I made a hie.yaml that looks like this:

cradle:
  multi:
    - path: "./hs"
      config:
        cradle:
          stack:

But, when I run it, I now get

⫸ ~/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-0.3.0-darwin --project-ghc-version
Found "./reach-lang/hie.yaml" for "./reach-lang/a"
Module "./reach-lang/a" is loaded by Cradle: Cradle {cradleRootDir = "./reach-lang", cradleOptsProg = CradleAction: Stack}
8.6.5

This is because my global Stack project is 8.6.5.

I also tried

cradle:
  stack:
    - path: "./hs/src"
      component: "reach:lib"
    - path: "./hs/test"
      component: "reach:test:reach-test"
    - path: "./hs/app"
      component: "reach:exe:reachc"

and

cradle:
  multi:
    - path: "./hs"
      config:
        cradle:
          stack:

and

cradle:
  multi:
    - path: "./hs"
      config:
        cradle:
          stack:
            - path: "./src"
              component: "reach:lib"
            - path: "./test"
              component: "reach:test:reach-test"
            - path: "./app"
              component: "reach:exe:reachc"

But none of these work.

What is the correct way for the sole stack.yaml in my project to be in a sub-directory of the directory hie-bios is run from?

[fendor]

Hi, thank you for the bug report!

I think you may use the latest feature of 0.7.0.0: #230 (Documentation: https://github.com/mpickering/hie-bios#stack)
I am not sure if hls or ghcide have updated to that version yet, but you can give it a try via the hie-bios executable.
The hie.yaml would look like this:

cradle:
  multi:
    - path: "./hs"
      config:
        cradle:
          stack:
            stackYaml: "./hs/stack.yaml"
            components:
              - path: "./src"
                component: "reach:lib"
              - path: "./test"
                component: "reach:test:reach-test"
              - path: "./app"
                component: "reach:exe:reachc"

Then try to invoke hie-bios debug hs/src/<SomeModulePath>.
Does that work?

[jeapostrophe]

I'd love to test it. I'm sorry but I don't know how to begin with the source release of hie-bios. I downloaded and tried cabal configure and cabal build but both errored that they couldn't find ghc (I use Stack) so then I did stack exec -- cabal install and got a bunch more errors.

So... how do I actually build the hie-bios and test it? I'm happy to be sent to a manual to read about it

[fendor]

Sorry, indeed, hie-bios does not support stack by default. You can clone the project hie-bios via git and then generate a stack.yaml via

> stack init  --resolver lts-16.11 --ignore-subdirs --force

I tested that hie-bios actually builds with that resolver.
Then you may just use stack install to install the executable to ~/.local/bin (if you're on windows it is somewhere complicated, check with stack path --local-bin).
Then it should be possible to invoke hie-bios debug ./hs/src/<ModulePath>.

[jeapostrophe]

Thanks, I built it and ran with that config file. I get this result:

⫸ /Users/jay/Downloads/t/hie-bios-0.7.0/.stack-work/install/x86_64-osx/4380b75e914ab81bfb591f06f05c83badebf788b29113ede8a4bc71ac1a72eda/8.8.3/bin/hie-bios debug ./hs/src/Reach/Eval.hs
Cradle failed to load
Deps: []
Exit Code: ExitSuccess
Stderr: Multi Cradle: No prefixes matched
pwd: /Users/jay/Dev/scm/bitbucket.jeapostrophe/reach/reach-lang
filepath: /Users/jay/Dev/scm/bitbucket.jeapostrophe/reach/reach-lang/hs/src/Reach/Eval.hs
prefixes:
("./src",Stack {component = Just "reach:lib", stackYaml = Just "./hs/stack.yaml"})
("./test",Stack {component = Just "reach:test:reach-test", stackYaml = Just "./hs/stack.yaml"})
("./app",Stack {component = Just "reach:exe:reachc", stackYaml = Just "./hs/stack.yaml"})

If I run the cradle command, I get this:

⫸ /Users/jay/Downloads/t/hie-bios-0.7.0/.stack-work/install/x86_64-osx/4380b75e914ab81bfb591f06f05c83badebf788b29113ede8a4bc71ac1a72eda/8.8.3/bin/hie-bios cradle ./hs/src/Reach/Eval.hs 
Cradle for "/Users/jay/Dev/scm/bitbucket.jeapostrophe/reach/reach-lang/hs/src/Reach/Eval.hs": Cradle {cradleRootDir = "/Users/jay/Dev/scm/bitbucket.jeapostrophe/reach/reach-lang/hs", cradleOptsProg = CradleAction: Stack}

I also tried a simpler hie.yaml and got the same result:

cradle:
  multi:
    - path: "./hs"
      config:
        cradle:
          stack:
            stackYaml: "./hs/stack.yaml"

Although may it is good to have the more complex one, I don't really know

So anyways... I don't really know if this means it will work in the new version, but if you know that it does, then I guess we can close this issue and I'll just make a note to use the new config option when the other parts of the pipeline get updated.

Thank you for the fast response! I tried to use stackYaml yesterday, but when it was rejected, I didn't think to try using a new version. Sorry for the noise!

[fendor]

I debugged this a bit now.
I got it to work with the following config:

cradle:
  multi:
    - path: ./
      config:
        cradle:
          none:

    - path: ./simple-stack/
      config:
        cradle:
          stack:
            stackYaml: ./simple-stack/stack.yaml
            components:
              - path: ./simple-stack/src
                component: simple-stack:lib
              - path: ./simple-stack/exe
                component: simple-stack:exe:simple-stack-exe
              - path: ./simple-stack/test
                component: simple-stack:test:simple-stack-test

Somewhat under documented, the paths within in the multi-cradle are still relative to the location of hie.yaml.

The multi-cradle is a list of relative paths and cradle configurations. The path is relative to the configuration file and specifies the scope of the cradle.

I am unsure how well this plays in practice with real projects, yet, but would be happy about feedback!

[jeapostrophe]

Thanks! Do you know if it possible to get the haskell-ide-engine that came with the VSCode extension to use a hand-built version of this?

Also, it might be nice to be allowed to have hie.yaml file in ./simple-stack/ with its own information in there.

[fendor]

I think with VSCode comes haskell-language-server and unfortunately, you can only use it by building it from source. However, if you wait for the next release, which should be in a day or two, then you can download the new binaries.

Also, it might be nice to be allowed to have hie.yaml file in ./simple-stack/ with its own information in there.

Indeed, that would be nice. Judging by a quick test, it seems the main problem is that the wrapper can in that case not figure out which type of project it is being invoked on.
E.g. for me:

Module "/home/munin/Documents/haskell/t/a" is loaded by Cradle: Cradle {cradleRootDir = "/home/munin/Documents/haskell/t", cradleOptsProg = CradleAction: Default}

where /home/munin/Documents/haskell/t/a is a dummy module and the root dir is like the root in your project.
The action type CradleAction: Default tries to use the ghc version on the PATH to figure out which version of HLS it should start, which does not work for you (and works for me by accident since I have ghc 8.8.3 on the PATH). The version of HLS is important, since we need to start a HLS version that is compiled with the same ghc version as your project.

So, if you are always working on stack projects with the same ghc version (e.g. all have lts-16.11 or something like that), then you can skip the wrapper script and launch the appropriate HLS version in VSCode directly. Maybe we can solve this issue on the HLS side.

[jeapostrophe]

Thank you!