Intermittent "failed to load packages, cannot satisfy -package <main-lib>" from components other than <main-lib>

[googleson78]

I "randomly" get errors like ghcide compiled by GHC 8.8 failed to load packages: <command line>: cannot satisfy -package main-lib-name-0.1.0.0 when trying to use ghcide/hls on a component that isn't the main library.

Yes, I am using a matching version.

The component I'm currently trying to use has some compilation errors (redundant imports + -Werror), that did indeed pop up when I tried to run hls(/ghcide) from the command-line, however after them, the error from above pops up also, seemingly overwriting the previous errors from when trying to use hls/ghcide from within an IDE (nvim + LanguageClient-neovim). When I fix these errors I can load the component/file just fine.

I'm using stack.

Here's a version of the hls log, with concrete names edited out: https://gist.github.com/googleson78/bb431e4cdd791ddafed36200fdbc2a16

Is there anything I can do while in this "state" to provide more debug info/attempt some kind of fix?

[pepeiborra]

If the component C1 that you are trying to use is a dependency of the component C2 that you are trying to load, C2 -> C1, then it is likely that the C2 cradle will fail when trying to build C1 (since it is a dependency), preventing the flags from C2 from being computed.

In case it adds clarity, multi-cradle support would load C2 after having already loaded C1 as follows:

0. Run the cradle for C1, parse and load the flags into a new Ghc session S1
1. Run the cradle for C2, e.g. call Cabal which will build all the deps and return a set of flags and targets
2. Parse and load the flags and targets into a new, fresh Ghc session S2
3. Create a new Ghc session S12 with flags(S1) + flags(S2) - package-id(C1). That is, merge both sets of flags removing all the package flags that reference C1.

[googleson78]

It's the opposite - I'm trying to use C1 (a test suite), which depends on C2 (the library of the package)

C2 builds fine
C1 doesn't build, but in my vim, instead of seeing the compilation errors, I just get what amounts to "cannot find package C2"

If I run hls/ghcide via command-line I do see the compilation errors, but right after that I get the "can't find" error, which I'm assuming overrides the compilation errors for my LSP client.

[pepeiborra]

Is this with a stack or cabal cradle? Does it work with either?

[googleson78]

stack, haven't tried cabal, and I unfortunately haven't found out the exact sequence of steps to repro it yet. It just seems to happen "at random" but often enough that it's annoying.

Sorry for the "ghost story" issue!

[Martoon-00]

For me, this issue reproduces all the time, cannot build tests and executables using ghcide. Though my project has several subpackages depending one on another, and library code builds fine in all of them.

Whether my component (e.g. a test suite) has building errors or not does not influence the outcome. Even if they are there, I never see them reported, only that cannot satisfy -package error.

I'm also using GHC 8.8 and stack, having a hard time trying to make cabal work (for some other reasons). Running from VSCode.

Hope this clarifies some bits.

[jneira]

@Martoon-00 It would be great to have access to some project that reproduces consistently the error, is it open source?

[googleson78]

Here's a reproducer, at least for me:
https://github.com/googleson78/ghcide842

0. Clone repo
1. cd lols
2. haskell-language-server-wrapper test/Spec.hs
3. Instead of getting only the proper type error from ghc, I also get

     ghcide compiled by GHC 8.8 failed to load packages: <command line>: cannot satisfy -package
     lols-0.1.0.0
     (use -v for more information).
     Please ensure that ghcide is compiled with the same GHC installation as the project.
   

[dnikolovv]

Just chiming in to say this has been reproducing for me 100% of the time. I've never been able to get to build any test or executable using ghcide if it had any compiler errors to start with.

[0rca]

This also happens to me, but it goes away after I compile <project>:lib target with stack build and restart the language server.

[jneira]

@googleson78 hi, thanks for the small reproducer.
That project has an error in the exe component:

D:\ws\haskell\ghcide842\lols\app\Main.hs:6:8: error:
    * Couldn't match expected type `IO ()'
                  with actual type `String -> IO ()'
    * Probable cause: `someFunc' is applied to too few arguments
      In the expression: someFunc
      In an equation for `main': main = someFunc
  |
6 | main = someFunc
  |        ^^^^^^^^

Not sure if it is needed to trigger the issue but:

• fixing the executable error and make a stack clean the issue is still reproduced
• fixing the executable error and make a stack clean and a stack build (builds the lib and the fixed executable) makes the issue gone for me

EDIT: i think this match you initial description.

[jneira]

• Consider this shell session using hie-bios:

D:\ws\haskell\ghcide842\lols>hie-bios check test\Spec.hs
hie-bios: <command line>: cannot satisfy -package lols-0.1.0.0
    (use -v for more information)

D:\ws\haskell\ghcide842\lols>stack build
Building all executables for `lols' once. After a successful build of all of the
m, only specified executables will be rebuilt.
lols> configure (lib + exe)
Configuring lols-0.1.0.0...
lols> build (lib + exe)
Preprocessing library for lols-0.1.0.0..
Building library for lols-0.1.0.0..
Preprocessing executable 'lols-exe' for lols-0.1.0.0..
Building executable 'lols-exe' for lols-0.1.0.0..
[1 of 2] Compiling Main

D:\ws\haskell\ghcide842\lols\app\Main.hs:6:8: error:
    * Couldn't match expected type `IO ()'
                  with actual type `String -> IO ()'
    * Probable cause: `someFunc' is applied to too few arguments
      In the expression: someFunc
      In an equation for `main': main = someFunc
  |
6 | main = someFunc
  |        ^^^^^^^^

--  While building package lols-0.1.0.0 using:
      D:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8
.4.exe --builddir=.stack-work\dist\29cc6475 build lib:lols exe:lols-exe --ghc-op
tions ""
    Process exited with code: ExitFailure 1

D:\ws\haskell\ghcide842\lols>code app\Main.hs
# Fix the app\Main.hs error

D:\ws\haskell\ghcide842\lols>stack build
Building all executables for `lols' once. After a successful build of all of the
m, only specified executables will be rebuilt.
lols> configure (lib + exe)
Configuring lols-0.1.0.0...
lols> build (lib + exe)
Preprocessing library for lols-0.1.0.0..
Building library for lols-0.1.0.0..
Preprocessing executable 'lols-exe' for lols-0.1.0.0..
Building executable 'lols-exe' for lols-0.1.0.0..
[1 of 2] Compiling Main
[2 of 2] Compiling Paths_lols
Linking .stack-work\dist\29cc6475\build\lols-exe\lols-exe.exe ...
lols> copy/register
Installing library in D:\ws\haskell\ghcide842\lols\.stack-work\install\3279a157\lib\x86_64-windows-ghc-8.8.4\lols-0.1.0.0-HWdZs8N8U517rrHkgeb9yv
Installing executable lols-exe in D:\ws\haskell\ghcide842\lols\.stack-work\install\3279a157\bin
Registering library for lols-0.1.0.0..

D:\ws\haskell\ghcide842\lols>hie-bios check test\Spec.hs
test\Spec.hs:5:3: Couldn't match expected type ‘IO a0’ with actual type ‘String -> IO ()’
• Probable cause: ‘someFunc’ is applied to too few arguments
  In a stmt of a 'do' block: someFunc
  In the expression:
    do someFunc
       putStrLn "Test suite not yet implemented"
  In an equation for ‘main’:
      main
        = do someFunc
             putStrLn "Test suite not yet implemented"

So this has definitely a hie-bios origin, and afaik it is a known one: hie-bios can load a stack (?) test component if the lib/exe components has errors (cause stack builds at once lib+exe by default).
I guess in general it can load a component if the components on which it depends have errors.
I dont find a issue describing it though (//cc @fendor)

[googleson78]

I was not intending there to be an error in the executable, but it still matches my original description, yes - instead of having the errors reported for the executable, I just get a blanket "can't load component".
Thanks for looking into it!

[googleson78]

Also, I'm sorry for asking slightly meta/unrelated questions, but what is the workaround for this (since you added a can-workaround tag)? I would love to use it for the time being, if it's not too annoying!

[jneira]

@googleson78 mmm, if the issue is reproduced with no errors in the lib or exe component, i am afraid i still have to reproduce it.
I cant reproduce it taking your repo as base and correcting the exe main error (plus stack clean and stack build).

The "workaround" was to no load a component (i.e. dont open a component file in the ide) while there are errors in other components on which it depends on but it seems that it does not work for you so correcting labels.

[20dchen01]

@googleson78 hi, thanks for the small reproducer.
That project has an error in the exe component:

D:\ws\haskell\ghcide842\lols\app\Main.hs:6:8: error:
    * Couldn't match expected type `IO ()'
                  with actual type `String -> IO ()'
    * Probable cause: `someFunc' is applied to too few arguments
      In the expression: someFunc
      In an equation for `main': main = someFunc
  |
6 | main = someFunc
  |        ^^^^^^^^

Not sure if it is needed to trigger the issue but:

* fixing the executable error and make a `stack clean` the issue is still reproduced

* fixing the executable error and make a `stack clean` and a `stack build` (builds the lib and the fixed executable) makes the issue gone for me

EDIT: i think this match you initial description.

I just want to add in that this worked for me too.

[jneira]

@googleson78 so to be sure, and sorry for asking for already provided info, what is your project state when the errors is triggered? i am assuming that:

• there is no errors in dependant components (for stack they will be lib and exe, even if test component only depends on the lib)
• there is an error in a dependent component (typically the test component)
• you still got (intermitently)

 ghcide compiled by GHC 8.8 failed to load packages: <command line>: cannot satisfy -package
  packagename-version
  (use -v for more information).
  Please ensure that ghcide is compiled with the same GHC installation as the project.

when trying to load a file from the test component, instead the legitimate compile error.

That is the state that i cant reproduce.

[googleson78]

Your "state description" is correct. However, my given reproducer from above also no longer works for me for the issue! If it pops up again, I'll try to make another reproducer and report back.

Maybe(hopefully) some changes in ghcide "accidentally" fixed this issue?

(sorry for the inconvenience and thanks for your time!)

[jneira]

Maybe(hopefully) some changes in ghcide "accidentally" fixed this issue?

Given we released hls-0.6.0, including a ghcide bump to ghcide-0.5.0, it may be the case.
I'll keep open it for a while, just in case you or other user hit the same issue.

[Martoon-00]

Once I tried the steps from the post above on the project suggested by @googleson78, the issue is also gone for me, I get exactly the same results. This seems to also help for other projects, so for me this is a working workaround. Really not sure how didn't I find this solution before 😅

I can reproduce the issue in that project again doing:

• break someFunc method in the executable back
• stack clean --full or rm -rf .stack-work (mere stack clean is not enough)
• stack build - build fails at Main.hs
• run ghcide

So looks like I just need the target package to be built at least once, maybe even at another branch, to avoid the issue.

[domenkozar]

I've also hit this with hls-0.6.0.

A simpler workaround is to do stack build mypackage:lib and reload your editor.

[C-alcium]

I get this as well. I thought originally that it was my nvim setup, but trying with VSCode produces the same error, same message/situation as above.

I will say for my specific case I don't actually get any error other than the satisfy package error. So, I was fairly lost until I navigated to the command line and issued a stack build to see what the real problem was, which confused me even further because this error appears on the module statement for some reason.

[googleson78]

Another observation: if I get it to a working state by doing the "build lib manually" workaround, and then change something in the lib, I have to do the workaround again.

[drsooch]

Another observation: if I get it to a working state by doing the "build lib manually" workaround, and then change something in the lib, I have to do the workaround again.

I can confirm this is how I've been working for the last couple of days. Anytime my project recompiles (the executable or test-suite) it seems to pop the error again. I can't say for certain but I am 95% sure it's when there is a compile error in the dependent component.

If it helps any, I have my ghc-options set for "$targets": -Werror in stack.yaml. After changing this I can't seem to reproduce it (did only minor testing).

[googleson78]

This is extremely annoying, is there anything I can do to push this forward? Any clues for what's going on, i.e. where one should look if they choose to look into this?

[jneira]

summoning @fendor in case we can do something in the hie-bios component, at least link an issue that tracks stack needed changes (if that is the case, i am not sure tbh)

[sekunho]

Ran into this issue as well in VSCode. I had to restart the editor every time the "could not find module" error pops up, which is pretty tiring to do. I also tried out what @googleson78 instructed in #1909, and I think I was able to reproduce the issue reliably outside VSCode with just HLS. So it seems to be an HLS issue since Stack detects the modules just fine, while HLS complains about it not finding the module.

After trying it out with just HLS, I hopped onto VSCode, and HLS reported a different issue, which was also mentioned in the original post, about not satisfying the package. To which I had to stack clean and stack build for it to go away. But the main issue still remains that HLS does not detect the new modules until I perform a full editor restart.

You can try it out in this repo: https://github.com/hsek/quad-ci/tree/fa44eb79b6b6085fc7326f88973e5047936d7efd

Sample module is the new module I introduced, which HLS failed to detect but Stack did just fine. You'd have to make a new one, then import it to the test/Spec.hs. Following this with just HLS provided in nix will give a different error compared to stack, which is detailed here.

[ghost]

You don't need to restart VSCode, just need to restart the LSP after run stack clean && stack build. Still very annoying.

The best thing I can do at the moment is combining all those steps to tasks.json like this:

{
    "group": "build",
    "type": "shell",
    "label": "haskell clean & build",
    "command": "stack clean && stack build"
},
{
    "label": "rebuild and reload LSP",
    "command": "${command:haskell.commands.restartServer}",
    "dependsOn": [
        "haskell clean & build"
    ]
}

[jneira]

@Fubuchi thanks for the tip to automate the workaround, sweet!

[fyusuf-a]

I get this problem with haskell-language-server v1.2.0.0 and it does not go away with stack clean && stack build. Of course, the versions are the same. It is utterly annoying.

[jneira]

@fyusuf-a do you use an older version of hls due to some reason?

[sekunho]

I think it might be setup with nix cause afaik it's still at 1.2.0.

[jneira]

hmm dont know much about nix but i think other maintainers uses the last version 🤔

[jneira]

@hsek agree in this should be annoying but at least the workaround works for you?

[sekunho]

I've moved to emacs + cabal so I'm not sure, sorry. But I'll make sure to report back when I do run into a stack project.

[fyusuf-a]

@fyusuf-a do you use an older version of hls due to some reason?

@jneira The building process of hls is quite long. I built it like 6 months ago I guess with ghc-8.8.4 if I remember correctly and I have not had the courage to build it again since. I will try and use the last version and keep you posted.

[jneira]

Ok i think this is essentially #366 and is triggered in test/exe/bench components if the package lib has a compile errors when loading the project. Observe the error message is the same as #366 (comment)
@googleson78 and the rest of participants: thanks for the tests and the info provided. If any of you thinks this issue differs from #366 please reopen.
Will post the @Fubuchi workaround there

[meSmashsta]

Guys, I am still experiencing this issues, work around was doing what this comment instructed:
#735 (comment)

[ProofOfKeags]

I am now encountering this. Seems that the workarounds no longer work. It just randomly stopped working on me. Don't know how to get it back to a state where it was working.

EDIT: this seems to be an issue with the stack cradle, switching to the cabal one fixes it. Discovered solution in #366 referenced above

[sebastian-j-ibanez]

This also happens to me, but it goes away after I compile <project>:lib target with stack build and restart the language server.

I was having this issue with a newly initialized stack project and HLS. I can confirm that the issue goes away after building and reconnecting to HLS.

(I work on Emacs 29 with eglot)