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

Created on 1 Oct 2020  Â·  20Comments  Â·  Source: haskell/ghcide

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?

can-workaround hie-bios bug setup

Most helpful comment

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

  1. Clone repo
  2. cd lols
  3. haskell-language-server-wrapper test/Spec.hs
  4. 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.

All 20 comments

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:

  1. Run the cradle for C1, parse and load the flags into a new Ghc session S1
  2. Run the cradle for C2, e.g. call Cabal which will build all the deps and return a set of flags and targets
  3. Parse and load the flags and targets into a new, fresh Ghc session S2
  4. 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.

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.

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

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!

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.

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

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

  1. Clone repo
  2. cd lols
  3. haskell-language-server-wrapper test/Spec.hs
  4. 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.

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.

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

@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.

  • 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)

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!

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!

@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.

@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.

@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.

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!)

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.

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 :sweat_smile:

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.

I've also hit this with hls-0.6.0.

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

Was this page helpful?
0 / 5 - 0 ratings