"Cannot satisfy -package-id" after editing dependency

[k-bx]

trafficstars

Just installed latest ghc-mod to try it out with stack. My project looks like this:

proj/stack.yaml
proj/proj-main
proj/proj-shared
proj/somelib

stack.yaml looks something like this:

packages:
- proj/proj-main
- proj/proj-shared
- proj/somelib

In cabal files proj-main depends on both proj-shared and somelib, proj-shared depends on somelib.

So, I was working on proj-main sources, then I needed to add something to somelib. I edited somelib, but now, when I edit that file in proj-main and save it, I see an error like this:

<command line>: cannot satisfy -package-id somelib-0.1.0.0-da9b3c4909a3f015e12d703130c3d265
    (use -v for more information)

Running sudo killall -9 ghc-mod didn't help. Running stack build form terminal didn't help either (it built fine, showing actual errors in file I'm editing from proj-main). Restarting emacs doesn't help.

What's the cause? Please help.

UPDATE: emacs restart didn't help, sorry for confusion

[DanielG]

Same thing as here probably: https://github.com/kazu-yamamoto/ghc-mod/issues/605

[k-bx]

@DanielG I'm not sure I see how. I'm on 7.8.4 for work-project and used it to install ghc-mod also. Should that be ok?

Another weird thing is that it worked fine initially, until I updated that dependant library.

[DanielG]

I'll properly think about this tomorrow I'm at home now :P

[k-bx]

@DanielG sure, thank you :)

[k-bx]

Just in case: "stack clean" helped. Of course, I needed to rebuild all my non-stackage-snapshot dependencies on next build, but at least this is something.

UPDATE: broken again on dependency-edit. So it's reproducing, I think.

[k-bx]

One more thing: doing:

sudo killall ghc-mod
rm -rf proj-main/.stack-work
rm -rf proj/proj-shared/.stack-work
rm -rf proj/somelib/.stack-work

Helped without a need to re-install dependencies, since they're in proj/.stack-work. Maybe only removing proj/somelib/.stack-work would help, not sure.

[DanielG]

Can you try removing .stack-work/dist/*/Cabal-*/setu-config.ghc-mod.* those are our persistent caches that might be getting in the way again and not being invalidated properly. If that doesn't help then this sounds like a problem in stack because ghc-mod just uses whatever package versions it finds in Cabal's setup-config state file.

[k-bx]

@DanielG just checked – yes it helps removing them. I'd be happy to provide more details. I reproduced bug on a fresh set of projects, so it's also reproducible.

[DanielG]

My guess is it has to do with this being a superproject since we didn't actually test that I think. I don't have time to debug this myself but if you want to go digging I can give you some pointers.

Basically you need to find out 1) if stack build --only-configure is being executed as it should be and if it is 2) why that's not changing the setup-config file or alternatively 3) why ghc-mod doesn't invalidate it's own caches even though setup-config changed.

[k-bx]

@DanielG even manually making sure stack has up-to-date setup-config (removed it and ran stack build to make sure) didn't help. Still getting:

<command line>: cannot satisfy -package-id proj-shared-0.1.0.0-661925d955e7e0389cf64d7db21a26a3
    (use -v for more information)

Grepping shows only file that has this package id is ./proj1/.stack-work/dist/x86_64-osx/Cabal-1.18.1.5/setup-config.ghc-mod.resolved-components, which makes me think only the last case is happening (ghc-mod doesn't invalidate its own caches for some reason). I have no idea why, unfortunately. Hope this helps.

[nrolland]

where does ghc-mod find its library ?

If launched with command line, from the location of ghc-mod debug, say GHC System libraries: /Users/nrolland/.nix-profile/lib/ghc-7.10.2

from stack exec -- ghc-mod boot this will add the stack package database hierarchy :

GHC_PACKAGE_PATH=/Users/nrolland/clones/client-json/.stack-work/install/x86_64-osx/lts-3.6/7.10.2/pkgdb:/Users/nrolland/.stack/snapshots/x86_64-osx/lts-3.6/7.10.2/pkgdb:/nix/store/4q88j6dv374dzkyvriq0ppcdg1zdsc5d-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d

but where should it be declared that emacs use stack exec -- ... and not the barebone version ?

[DanielG]

I think I need a test case to debug this in any meaningful way, so if anyone wants to construct an simple project that exhibits this problem or just link me to an existing one that would be terrific.

[nrolland]

as for me, somehow my emacs config was generating a "dist" directory automatically... leading to the known issue with stack

[k-bx]

@DanielG I created a repo with clear instructions on how to reproduce. Please, check it out!

[k-bx]

@DanielG oops, repo is at https://github.com/k-bx/ghcmod-bug

[PierreR]

:+1: I have experienced the exact same problem and needed to remove .stack-work to have ghc-mod working again (stack build was fine all along) @k-bx thanks for the provided tips

[nrolland]

I have the same here with message

ghc-mod -v7 --ghcOpt=v7 boot                                                                       not sandboxed
DEBUG: reading cache: /Users/nrolland/Sync/clones/cqrs/cqrs-example/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup-config.ghc-mod.package-options
ghc-mod: <command line>: cannot satisfy -package-id aeson-0.8.1.1-8e47ef90edf199d539b7274d4f606480:
    aeson-0.8.1.1-8e47ef90edf199d539b7274d4f606480 is unusable due to missing or recursive dependencies:
      attoparsec-0.13.0.1-216ae6d1d7012afee7211e449ede509a base-4.8.2.0-cc43d8e06aa74e9c4c0132becc49ee25 bytestring-0.10.6.0-04b5cc1d05f993b3b016543ca2863add containers-0.5.6.2-1281f6ac62b47acf472f6cdcec6a4f4b deepseq-1.4.1.1-8eec8f9bea2efc2500f63544ec6ca569 dlist-0.7.1.2-220d0c7d28c858a7c7c383616eebf3ec ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e hashable-1.2.3.3-ee603cbb62c7074d038c92a48f49cdd0 mtl-2.2.1-3af90341e75ee52dfc4e3143b4e5d219 scientific-0.3.4.4-303da0136a17ecbaabf28d709dc485b0 syb-0.5.1-b128945b001cd3d60bac71984040b818 template-haskell-2.10.0.0-c5036b5d1f11290a936c690d2f1bbd7f text-1.2.1.3-af4efec8ee6e081b079a34e976839d62 time-1.5.0.1-9d583724234c876226763fdd0cb776fc transformers-0.4.2.0-81450cd8f86b36eaa8fa0cbaf6efc3a3 unordered-containers-0.2.5.1-3cb0d6140328470c7dc1a6b72ebf8b5b vector-0.11.0.0-324da2b07f25721d305480db94a9f1d6
    (use -v for more information)

how can stack succeed and not ghc-mod ? that's odd. is there another place where we switch to cabal mode ?

[nrolland]

same after nuking .stack-work

$ ghc-mod -v7 --ghcOpt=v7 boot                                                                       not sandboxed
DEBUG: regenerating cache: /Users/nrolland/Sync/clones/cqrs/cqrs-example/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup-config.ghc-mod.package-options (cache missing or unreadable)
DEBUG: writing memory cache: /Users/nrolland/Sync/clones/cqrs/cqrs-example/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup-config.ghc-mod.package-options
ghc-mod: <command line>: cannot satisfy -package-id aeson-0.8.1.1-8e47ef90edf199d539b7274d4f606480:

[nrolland]

I think my issue is linked to ghc-7.10.3, going from nightly-2015-12-16 (7.10.3) to nightly-2015-12-13 (7.10.2) fixed it.

[mattjbray]

I had the same issue when starting a new project using LTS Haskell 4.1 (first time using 7.10.3 on this machine). Re-building ghc-mod with 7.10.3 seems to have solved the issue for me:

git clone [email protected]:DanielG/ghc-mod.git
cd ghc-mod
git log -n1 --oneline
# 2066a19 Merge branch 'lierdakil/fix-722'
stack install --resolver lts-4.1

[k-bx]

I think this is resolved, at least for me on latest ghc-mod.

[PierreR]

Same problem again after switching from lts-5.x to lts-6.x

ghc-mod is compiled with the same ghc-7.10.3 version (I am using nixos):

ghc-mod version 5.5.0.0 compiled by GHC 7.10.3

I have tried to remove ~/.ghc-mod with no success. Is there some sanity check to would make this tool working reliably ?

ghc-mod check Puppet/Lens.hs 
ghc-mod: <command line>: cannot satisfy -package-id aeson-0.11.2.0-181223a860910931da68bf6d2b8d25db: 
    aeson-0.11.2.0-181223a860910931da68bf6d2b8d25db is unusable due to missing or recursive dependencies:
      attoparsec-0.13.0.2-b08e0531a24ddda843e8da5d8efb6783 dlist-0.7.1.2-dfced2f12f4865c344b65c528c5600e3 fail-4.9.0.0-dd8812a5b6b0a0ce790ee5a93be03a9d hashable-1.2.4.0-98b6da14b6f369cf8e5b61483ede3e37 mtl-2.2.1-3af90341e75ee52dfc4e3143b4e5d219 scientific-0.3.4.6-df409432c87751486bc406c86ef2f5fb semigroups-0.18.1-5757edf1fce6735c27ed0ddf42021276 syb-0.6-d154b8ffa473f7cfcfc32ca4d99f62f7 text-1.2.2.1-d0adb978563e9f52dc308d1d0db7212c unordered-containers-0.2.7.0-8d62fe61f7bd9f027cec5b56846824b6 vector-0.11.0.0-299aefb173ce5a731565d31f609a0cfd

[erikkaplun]

I'm having the same issue with 7.10.3; I tried recompiling ghc-mod as well as stack clean and rm -rf .stack-work to no avail. I'm on OS X 10.11.4, ghc installed under .stack/programs/x86_64-osx/ghc-7.10.3 (the global version, installed by homebrew, is 8.0.1 and sits under /usr/local/bin but I assume that's irrelevant)

$ ghc-mod check src/Lib.hs 
ghc-mod: <command line>: cannot satisfy -package-id base-4.8.2.0-cc43d8e06aa74e9c4c0132becc49ee25
    (use -v for more information)