"Could not find module" error on local imports

[tchoutri]

Expected Behaviour

Not showing any error when importing a local module in another module

Current Behaviour

This error message in Neovim's :messages buffer

Could not find module ‘My.Module’ Use -v to see a list of the files searched for.

Additional Notes

This issue is similar to #1069, but I use stack + hpack
How could I debug the root cause of those issues?

[BananchickPasha]

I have pretty the same issue, but i use ghc with plain Makefile. Steps to reproduce:

For excample, i have project like this.

├── A.hs
├── Main.hs (imports Foo and Bar)
├── Dir
│   ├── Foo.hs (imports Bar and A)
│   └── Bar.hs

If I open Main.hs, hie doesn't show any errors. But if i open Foo.hs, which imports Bar and A, hie sends "Could not find module ‘Dir.Bar’" and "Could not find module ‘A’" errors. If then i open A.hs and Bar.hs in my editor (probably, enough to send "textDocument/didOpen" action to hie, because I have this error both on neovim and vscode), and then switch back to Foo.hs all errors disappear.

[tim2CF]

The same issue with latest vim and hie-8.6.5 on macOS

[fendor]

@BananchickPasha We are not supporting plain ghc with Makefile out of the box.
However, you can add a custom hie.yaml where you specify the build dependencies yourself with a "direct" cradle. The package https://github.com/mpickering/hie-bios has some examples on how to define your project context.

@tchoutri the issue is not similar to #1069 as this is related to nix. It is possible that your issue has been fixed on latest master. If not, please provide more steps to reproduce your set-up and project.

@tim2CF Please provide more information, both prior posts have different problems.
What version of hie are your using, what is the project, stack version, cabal version, is it a stack or cabal project and if possible logs of a project you've been working on.

[qenep]

@fendor: I'm a first-time user of hie and hence not yet familiar with its architecture, so please do pardon potential ambiguity of expression. I'm not sure where the attribute the issue: it may be stack, ghcide, hie-bios, or anything else.

I used to experience similar issues with Intero and stack unless I'd rebuild the project's new dependencies. This doesn't work here.

Environment

I'm experiencing the same issue, as described by others, on Linux using

• stack exec cabal -- --version
  cabal-install version 2.4.1.0
  compiled using version 2.4.1.0 of the Cabal library
• stack --version
  Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2
• Stackage resolver: lts-14.18 (ghc-8.6.5) in my stack.yaml.
• hdevtools: version 0.1.8.0 (ghc-8.6.5-x86_64-linux, cabal-2.4.1.0)
• HLint v2.1.26, (C) Neil Mitchell 2006-2019
• neovim + coc: :CocInfo
  vim version: NVIM v0.3.4
  node version: v12.14.0
  coc.nvim version: 0.0.74-3712edf331
• :CocConfig:

{
  "languageserver": {
    "haskell": {
      "command": "stack",
      "args": ["exec", "ghcide", "--", "--lsp"],
      "rootPatterns": [
        ".stack.yaml",
        ".hie-bios",
        "BUILD.bazel",
        "cabal.config",
        "stack.yaml",
        "package.yaml"
      ],
      "filetypes": [
        "hs",
        "lhs",
        "haskell"
      ],
      "initializationOptions": {},
      "settings": {
        "languageServerHaskell": {
          "hlintOn": true,
          "languageServerHaskell.useHieWrapper": false,
          "useHieWrapper": false,
          "liquidOn": false,
          "diagnosticsDebounceDuration": 10,
          "completionSnippetsOn": true,
          "formatOnImportOn": true,
          "formattingProvider": "brittany"
        }
      }
    }
}

---

A trivial pathological counterexample

The following trivial project exhibits the mentioned behavior of hie once built:

1. stack new test-project-scotty && cd test-project-scotty
2. stack.yaml: modify dependencies: {base >= 4.7 && < 5; scotty}
3. stack setup
4. ./app/Main.hs:

   {-# LANGUAGE OverloadedStrings #-}
   
   module Main where
   
   import Data.Maybe  -- First letter `i` is highlighted as a note: redundancy.
   import Web.Scotty  -- First letter `i` is highlighted as an error: "Could not find module 'Web.Scotty'..."
   
   main :: IO ()
   main = scotty 3000 $ get "/" $ html "Hello World!"

5. stack build

---

Could not find module ‘Web.Scotty’ Use -v to see a list of the files searched for. |7 | import Web.Scotty | ^^^^^^^^^^^^^^^^^

What I can tell so far with certainty is that the issue pertains exclusively to the packages with specified hashes. No import from base is affected. This is not my system's base. I've observed the same with mtl and other libraries.

-- excerpt from below
, "-package-id=base-4.12.0.0"
, "-package-id=scotty-0.11.5-5bX7ciYVp5pLFVLwTO5PeP"
-- omitted

And as Pasha reports above, project-internal libraries exhibit the same issue.

To be more precise, there is no problem with the packages in

~/.stack/programs/x86_64-linux/ghc-8.6.5/lib/ghc-8.6.5/

So I suppose it should make sense to regress on other paths in find ~/.stack/ -type d -name "mtl*", for instance, and on other packages.

---

EDIT [2019-12-28 10:05, 10:35 UTC]

Indeed, another fresh tiny project of mine, using resolver: lts-12.28 (ghc-8.4.4), the packages base, filepath and directory belong to

~/.stack/programs/x86_64-linux/ghc-8.4.4/lib/ghc-8.4.4/

and provide good imports in the sense of the IDE (otherwise they compile properly). However, the packages path, path-io, and zip do not and raise the error markup. I suppose there are two backends at work, as noted. The issue comes up always with only one of them: the one that outputs the stated error message. The project compiles and works correctly. Here's my package.yaml for this second project.

dependencies:
- base >= 4.7 && < 5
- transformers
- mtl
# - zip-archive
- zip
- filepath
- directory
- path
- path-io

In addition, in this project, I've built both the packages zip and zip-archive with resolver: lts-14.18. Note that it is commented out. But when I switch the resolver in stack.yaml to lts-14.18, on the import expression

[i]mport Codec.Archive.Zip

(the position of error in nvim emphasized by square brackets), in the status bar I get the error

Ambiguous module name ‘Codec.Archive.Zip’: it was found in multiple packages: zip-1.2.0 zip-archive-0.4.1 |21 | import Codec.Archive.Zip | ^^^^^^^^^^^^^^^^^^^^^^^^

When I switch to lts-12.28, with which I did not build zip-archive but did build zip, after a few seconds, coc catches up and in the status bar I see the error

Could not find module ‘Codec.Archive.Zip’ Use -v to see a list of the files searched for. |21 | import Codec.Archive.Zip | ^^^^^^^^^^^^^^^^^^^^^^^^

which hdevtools: ~/.local/bin/hdevtools -- built and installed with lts-14.18 before. Note that stack path --local-bin supersedes any project-local binary.
In the "pathological" project above,

$ stack build hdevtools
$ stack exec hdevtools -- check app/Main.hs
<No output>

$ stack build hlint
$ stack exec hlint app/Main.hs
No hints

$ stack build hie-bios
$ stack exec which hie-bios
~/.local/bin/hie-bios  # (I installed previously to ~/.local/bin/hie-bios from lts-14.18, should be project-local otherwise)
$ stack exec hie-bios check app/Main.hs
app/Main.hs:5:1:Warning: The import of ‘Data.Maybe’ is redundant
  except perhaps to import instances from ‘Data.Maybe’
To import instances alone, use: import Data.Maybe()

this is precisely the redundancy hint that I see on the first letter of the import expression import Data.Maybe, it is of different syntax highlight in nvim, but of the same highlight shape --- the error that we are talking about here, which is a bug, is on the first letter of the other import expressions and is red.

I don't know which backend provides the import errors to coc, hie (hie-bios, ghcide), the language server, etc. Here is how it looks.

EDIT_END<<<

---

In the project sandbox: stack build hie-bios and then

stack exec hie-bios flags app/Main.hs gives

Options: ["-i"
, "-odir=/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/odir"
, "-hidir=/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/odir"
, "-hide-all-packages"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/src"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/autogen"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/global-autogen"
, "-stubdir=/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build"
, "-package-id=base-4.12.0.0"
, "-package-id=scotty-0.11.5-5bX7ciYVp5pLFVLwTO5PeP"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/test-scotty-exe"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/app"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/test-scotty-exe/autogen"
, "-i/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/test-scotty-exe/test-scotty-exe-tmp"
, "-rtsopts"
, "-with-rtsopts=-N"
, "-optP-include"
, "-optP/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/ghci/79fbbfcf/cabal_macros.h"
, "-ghci-script=/tmp/haskell-stack-ghci/44d98b12/ghci-script"
, "-package-db"
, "/home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/.stack-work/install/x86_64-linux/05bc0afa4f6c81add4ff2cc3889c9f5c5734456008cdbaea9b84feb4e19d6ade/8.6.5/pkgdb"
, "-package-db"
, "/home/qenep/.stack/snapshots/x86_64-linux/05bc0afa4f6c81add4ff2cc3889c9f5c5734456008cdbaea9b84feb4e19d6ade/8.6.5/pkgdb"
, "-package-db"
, "/home/qenep/.stack/programs/x86_64-linux/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d"]
Dependencies: ["test-scotty.cabal","package.yaml","stack.yaml"]

Remarks

The issue is common to hie-wrapper and ghcide backends alike (unless I'm mixing things up here --- my global hie was built a few months ago, likely before the deprecation of hie-core). I've surmised it might be due hlint or hdevtools, but can't tell for sure. First of all, there are two different highlights:

1. one is with the first letter of an import statement highlighted as an error, which is the bug,
2. the other one correctly as underscore module name when the package is not referenced in stack.yaml or project.cabal (after stack setup or specified manually).

Suggestion

It would be great to know whether there is a way to instruct hie to use a local stack/cabal sandbox instance (via stack exec) of a binary (hlint, brittany, hdevtools) as is done in my language-server config (cf. :CocConfig above).

---

In addition, slightly less related, I've been experiencing an issue with erroneous interface files in base: "expected 803 but got 805". In the stack sandbox of the same project, I rebuilt hdevtools and installed it globally (stack install hdevtools). This fixed this particular issue.

[fendor]

@qenep Thank you for this extremely detailed bug report, it is very helpful! It will take some time to analyse everything you reported, so I will just start with explaining hie-core and the like:
hie-core is what eventually became https://github.com/digital-asset/ghcide and was never used by hie. Thus, also never deprecated. However, see #1416, which states that we intend to eventually merge all efforts one way or another with the project.
Therefore, ghcide and hie are very different projects with a different feature set.
In the last week, we merged #1126 which completely overhauled how projects are built, e.g. removed the dependency on ghc-mod and instead usage of hie-bios.
So, I would ask to install the latest version of haskell-ide-engine and try to see if the error still arises.

I will address the other parts of your bug-report once I have something useful to say ;D

[qenep]

@fendor: Thanks for your quick reply. I will do as you suggest and report back.
To clarify, my remark on deprecation of hie-core referred to its state tag and description on Hackage. But I appreciate that you point this out so I now better understand the structure.

Now that you mention ghc-mod, I recall having the same issues a year ago or so with it when it would not build for newer versions of GHC, before Daniel expressed that he would deprecate ghc-mod. Back then, I was trying to integrate it with Intero in Emacs, but it would always result in such import errors as here, among others, and unfortunately I didn't have the opportunity to dig deeper into the issue.

---

You say that

ghcide and hie are very different projects with a different feature set.

I haven't had enough time yet to work with either, but have followed the discussions on Reddit and other public forums as well as blogs. My impression is that some participants expressed the sentiment that essentially ghcide were faster than but would lack significant features of hie. Some asserted that ghcide were in parity to hie, which obviously contradicts the architectural structure of hie, as you describe, so such assertions can be rooted in the lack of understanding of it. Maybe an infographic or a flow chart would aid users' comprehension.

In my fairly limited experience, having changed :CocConfig to use ghcide instead of hie-wrapper (in my case, via stack exec) with originally

"languageServerHaskell.useHieWrapper": true,
"useHieWrapper": true

has indeed improved the speed a bit, depending on the project size, and reduced memory consumption, andectodically by a half.

I've specified these details here because I'm not yet confident that I correctly specified the desired configuration. I've controlled the system processes and observed that indeed ghcide loads instead of hie-wrapper or hie-8.6.5 and such.

---

There is still a bit of ambiguity also in what hie users put forth in their blogs and what the instructions in the docs are: in the "rootPatterns" property, some use .stack.yaml (with the dot prefix, which I actually have never encountered), while others omit the dot. Apparently, there is a slight difference between the recommended configuration of coc in your docs, in coc docs, and in the blog post that I like and ghcide project description refers to (in the "coc.nvim" subsection).

As you can see above, I followed suite with with that blog post, and moved the configuration of the language server from "initializationOptions", to "settings". It is obvious that I don't know how to do it right. So I can't tell, for example, with certainty whether hlint or brittany (coincides with the default) are activated in either case, but I'll look into it a bit later.

---

Right now, to verify what I'm writing, with the language server configuration as stated in my first comment above (ghcide via stack exec), I've opened that pathological trivial project, no error or hint markup was displayed at all, wrote a bit of nonsense: simply "abc", and observed the system process

~/.stack/compiler-tools/x86_64-linux/ghc-8.6.5/bin/ghcide --lsp

slightly increase CPU load, and the abc was underlined. At the same time, I've been observing an

hie --lsp

process (global, i.e., from ~/.local/bin/, which is stack path --local-bin) getting traction, accumulating memory, until finally the red markup subject matter appeared on the import expression. I can't really tell why they work in concert like this. This hie binary was last modified 2019-11-01.
Alright, I see now, I built and installed the entire family of hie-8.* binaries and the hie and hie-wrapper binaries on 2019-11-01, not really "a few" months ago, as I asserted originally.

I hope this adds a couple of brush strokes to the picture.

But the obvious thing to do now is proceed as you suggested and build first hie-8.6.5 from HEAD.

---

The comment has become longer than intended. But I'd also like to express my gratitude for the privilege to use hie, and Haskell itself with GHC. In fact, I'm fascinated by the effort that is put into the unification of Haskell IDE tools. I do recognize that it is work in progress. But I deeply appreciate your and other contributors' effort. I truly believe in the project and will support you as I can.

[qenep]

Ok, now I've built and installed it,

$ git pull --recurse-submodules
$ stack ./install.hs hie-8.6.5
$ cd ~/projects/haskell/webapps/2019-12-27/test-scotty
$ nvim app/Main.hs

Just for completeness, I've tried what follows before and after installing the target build-data (no change).

Observations

The old error message remains,

Could not find module ‘Web.Scotty’ Use -v to see a list of the files searched for. |6 | import Web.Scotty | ^^^^^^^^^^^^^^^^^

A new error message

Now I get the additional error highlight on the first character in "abc" and an additional error message

Error:hie: "cannot satisfy -package-id test-scotty-0.1.0.0-EPn1ugIUbuFAdKkf7dPEnD
    (use -v for more information)"`

This message does not populate the :messages list in nvim.

I'm not sure why it appears. I don't think that it is appropriate, since I didn't touch the project. But once rebuild, and it did rebuild actually, this error message disappeared. So I suppose something in the relevant stack snapshot must have changed. All I did on this machine was to rebuild and install hie-8.6.5 (and later build-data).

EDIT [2019-12-28 19:50 UTC]: I've run

$ killall hie
$ killall ghcide
$ killall hdevtools

and opened the same file. First, only the red blocks appeared and only three hie --lsp process were spawned. A few seconds later, the stack exec ghcide invoked five ghcide processes. The behavior is the same, but the error of this subsection, about "cannot satisfy..." reappeared. And if I run stack build, it disappeared.

Then I quit nvim and repeated the termination of processes as it appeared that some were respawned by other instances of coc that were still running. Now the behavior has changed a bit. I didn't take a screenshot, but the red blocks suddenly were expanded for the whole width of the underlined term and the PRAGMA was all with red background but didn't emit any error message whatsoever. The message about "cannot satisfy..." would not appear, however.

But when I quit and opened nvim again, it all looked as before that: red block for the first char, PRAGMA as before, and again that message about "cannot satisfy..."

So next, as I'm writing this, I terminate node and everything else now explicitly, following the tree of spawned subprocesses

$ killall -9 -v node hie ghcide ghc
<... terminated successfully ...>
$ nvim app/Main.hs

And I see the picture prior to this edit, as outlined in this entire comment:

As you see the error message appears (but not in :messages). This file would not compile. But it would if would make no sense if, in order to avoid this hie error, I had to recompile on every sytax error, which is self-contradictory.

EDIT_END<<<

Another additional error message

The errors on "abc" are

1. the correct underlined one with a different margin mark (which vanishes once there is another

   [typecheck] [E] /home/qenep/projects/haskell/webapps/2019-12-27/test-scotty/app/Main.hs:12:1: error:
       Parse error: module header, import declaration ...

2. the correct background highlight error, which apparently stems from the same backend as in the import expression, but is unfortunately overlayered in the status bar with the [typecheck] error 1., so I have to move the cursor to see the other one. It is still in nvim's list of :messages and reads

   Parse error: module header, import declaration or top-level declaration expected. |12 | abc | ^^^

Interestingly, only this message appears in :messages but not the first one, and it repeats some 30 times there, maybe this is the number of keystrokes interacting with that abc line.

Blocking

In addition, as a result of adding the expression abc, the blue-background hint on the import of Data.Maybe vanished.

But it returns once I remove the nonsense expression abc. It would be great if the former wouldn't depend on the latter and would remain regardless.

Unfortunately, while blocked, LSP providers stop to work. So, for example, the normal-mode map K in nvim that opens the info box for the active word does not work. But, as far as I can tell, coc's other features do work. So it looks like the entire language server for Haskell gets blocked.
I believe this problem was there before the update of hie on my machine today. Maybe it deserves a separate ticket, feel free to advise me if necessary. I don't know in how far they are intertwined.

---

A closely related issue

A related issue that has just come up in this context: the following is obviously wrong but that abc expression is blocking all other error checks --- except for the buggy error message in line 5 (vim's :set relativenumber). As you see, neither the underlined nor the red-background block on the first character of the faulty expression appears.

---

Another closely related issue

Moreover, these two blocks with the red background disappear, whenever I suspend nvim (Ctrl-z) and then resume (fg) --- they reappear only after I switch to insert mode. Moving the cursor around in the normal or the visual (selection) mode has no effect, only the insert mode reinstantiates that second backend with the red-background block on the first character (I believe this is the hie process). To be clear, the underlining under abc persists (I believe this is the ghcide process), regardless of what I do (except when it is blocked as described previously).

[fendor]

The error message:

Error:hie: "cannot satisfy -package-id test-scotty-0.1.0.0-EPn1ugIUbuFAdKkf7dPEnD
    (use -v for more information)"`

Is likely to be caused by #1499. Later in the conversation, the work-around adding a hie.yaml with the contents:

cradle:
  stack:

also works.

You are suggesting multiple different features here, it would be useful to have them split into multiple issues.

Yes, parsing errors (which this "abc" is) happen early on the GHC phase, and it only reports those. So for an initial load, nothing else is possible. GHC does not give us more than that.
Caching the compiler results is possible, but expensive in memory usage and probably very tricky to get right. Same goes for caching hlint results.
Also, when we can not obtain a type-checked module, because of import-errors or parsing errors, we can not provide a lot of the functionality.

[qenep]

Ok, thanks for your reply, I'll investigate this further and split the issues as soon as I can, likely in a few days from now, and will report back.

As for the GHC limitation, I will just hope this would improve over time. I think as soon as hie gets sufficient traction, this could be tackled.

Have a Happy New Year!

[thalesmg]

I'm having a similar issue with Emacs and a multi-package Reflex project, hie-8.6.5. The local package frontend imports a module from common. It builds fine, but in Emacs it complains that it could not find module Common.

[fendor]

@thalesmg Please link logs and output from hie-debug --debug frontend/.

[thalesmg]

@fendor I do not have the hie-debug available. I installed it via Nix and https://github.com/Infinisil/all-hies .

Buffer *hie*

# empty

Buffer *hie::stderr*

Could not parse '/home/thales/dev/haskell/reflex-skeleton/frontend/stack.yaml':
Aeson exception:
Error in $: failed to parse field "snapshot": keys ["snapshot","resolver"] not present
See http://docs.haskellstack.org/en/stable/yaml_configuration/

I'm using only package.yaml files to describe each subpackage.

EDIT: I should add that HIE does work only with package.yaml, but with a single package (see the master branch of the repo below)

Branch: https://github.com/thalesmg/reflex-skeleton/tree/multiple-packages

Thanks for your reply!

[fendor]

I had a mental typo, I meant hie --debug frontend/.
But the error message suggests, that stack build fails?

EDIT:

EDIT: I should add that HIE does work only with package.yaml, but with a single package (see the master branch of the repo below)

I do not quite understand what you mean by that. Since you use a stack.yaml, hie will infer to use stack for buiding the project, but the stack.yaml seems invalid for normal stack projects?

MORE EDIT:
I mainly dont understand this project setup. In the stack.yaml, there is shell.nix specified which most likely refers to a shell.nix in the project root? Is this how it works?

[thalesmg]

hie --debug frontend/

ͳ hie --debug frontend/
2020-03-24 08:15:04.463840064 [ThreadId 4] - run entered for hie-wrapper(hie) Version 1.1 x86_64 ghc-8.6.5
2020-03-24 08:15:04.464079987 [ThreadId 4] - Current directory:/home/thales/dev/haskell/reflex-skeleton
2020-03-24 08:15:04.464136822 [ThreadId 4] - Operating system:linux
2020-03-24 08:15:04.464184158 [ThreadId 4] - args:["--debug","frontend/"]
2020-03-24 08:15:04.465546824 [ThreadId 4] - Cabal-Helper found these projects: []
2020-03-24 08:15:04.465727428 [ThreadId 4] - These projects have the build tools installed: []
2020-03-24 08:15:04.465768799 [ThreadId 4] - Could not find a Project for file: /home/thales/dev/haskell/reflex-skeleton/File.hs
2020-03-24 08:15:04.465801941 [ThreadId 4] - Module "/home/thales/dev/haskell/reflex-skeleton/File.hs" is loaded by Cradle: Cradle {cradleRootDir = "/home/thales/dev/haskell/reflex-skeleton", cradleOptsProg = CradleAction: Direct}
2020-03-24 08:15:04.465849547 [ThreadId 4] - Cradle directory:/home/thales/dev/haskell/reflex-skeleton
2020-03-24 08:15:04.465986602 [ThreadId 4] - Executing GHC on path with args: --numeric-version
2020-03-24 08:15:04.51239961 [ThreadId 4] - GHC Output: "Just "8.8.3""
2020-03-24 08:15:04.512633079 [ThreadId 4] - Project GHC version:8.8.3
2020-03-24 08:15:04.512814308 [ThreadId 4] - hie exe candidates :["hie-8.8.3","hie-8.8","hie"]
2020-03-24 08:15:04.515330782 [ThreadId 4] - found hie exe at:/nix/store/bnafh79hy83cbw72s4zqbj743zzxlmds-haskell-ide-engine-combined/libexec/bin/hie
2020-03-24 08:15:04.515502165 [ThreadId 4] - args:["--debug","frontend/"]
2020-03-24 08:15:04.515776147 [ThreadId 4] - launching ....



hie-wrapper couldn't find a HIE binary with a matching GHC version in your all-hies installation
hie: callProcess: /nix/store/bnafh79hy83cbw72s4zqbj743zzxlmds-haskell-ide-engine-combined/libexec/bin/hie "--debug" "frontend/" (exit 1): failed

I do not quite understand what you mean by that. Since you use a stack.yaml, hie will infer to use stack for buiding the project, but the stack.yaml seems invalid for normal stack projects?

No, I don't use a stack.yaml. I build the project using nix-build -A {ghcjs.frontend,ghc.backend} and nix generates the cabal files on the fly (notice in the repo that there are no stack.yaml nor *.cabal files). While trying to make this work, I tried to create a stack.yaml and forgot that in the wip commit, sorry about that 🙈.

But, indeed, stack build fails with the same error:

Could not parse '/home/thales/dev/haskell/reflex-skeleton/frontend/stack.yaml':
Aeson exception:
Error in $: failed to parse field "snapshot": keys ["snapshot","resolver"] not present
See http://docs.haskellstack.org/en/stable/yaml_configuration/

Is it possible to setup the project for HIE with only package.yaml and no {*.cabal,stack.yaml} files?

EDIT: I should add that I'm a Nix and Reflex newbie and still figuring thing out... 🙊

[fendor]

Is it possible to setup the project for HIE with only package.yaml and no {*.cabal,stack.yaml} files?

No, that is not supported. You would have to use hpack to generate a .cabal file.
Then you would need cabal to build the project. If you can build the project with cabal, then it ought to work. However, HIE does not know how to handle nix-projects.
If you know how to compile your project with ghc, e.g. you know the exact compile flags, then you can configure HIE to use exactly these compile flags, but this is complex.

[thalesmg]

I see. I'll have to research more if there is a way to use the cabal file that Nix generates automatically during the build.

building '/nix/store/cqhddrf6pfmbdda7p12n5brzb1ax4119-cabal2nix-reflex-skeleton-backend.drv'...
installing
*** found package.yaml. Using hpack...

Thanks for your help! 🍺