How to deal with multiple versions of the same package?

[mrkkrp]

Somehow I'm getting this:

Couldn't match expected type ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Internal.Path
                                b16 path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.File’
            with actual type ‘Path Abs File’
NB: ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Internal.Path’
      is defined in ‘Path.Internal’
          in package ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8’
    ‘Path’
      is defined in ‘Path.Internal’
          in package ‘path-0.5.3@path_FF4geOPnhyxDxuXRlWFMak’
In the first argument of ‘Dir.renameFile’, namely ‘apath’
In the third argument of ‘liftM2’, namely
  ‘(Dir.renameFile apath fpath)’

As I understand, I've got two versions of the same package. stack clean and even deletion of .stack-work do not help. How to deal with this situation?

[mrkkrp]

One more detail: it happens with Flycheck that uses stack ghc command internally.

[bergmark]

It seems to be two instances of the same version of the package, probably installed with different dependencies. Still, this shouldn't happen!

[mrkkrp]

I will try to upgrade to the latest Git version and re-check.

[mrkkrp]

No, the problem is still there. What can I do to reset this thing or something?

[borsboom]

Does stack exec ghc-pkg list show the package twice? There are some things you can do with stack that can lead to a strange snapshot database, such as messing with snapshot packages' ghc-options. Of course, entirely possible there is a bug. Chances are nuking ~/.stack/snapshots will reset it.

[mrkkrp]

stack exec ghc-pkg list does list it (path-0.5.3) twice: once in /usr/lib/ghc-7.10.3/package.conf.d: section and once in /home/mark/.stack/snapshots/x86_64-linux/nightly-2016-01-19/7.10.3/pkgdb: section.

I previously used one package that depends on path specifying its directory in stack.yml file. Then it was added to Stackage and I switched to the fresh nightly-2016-01-19 resolver instead. After that, the problem has manifested itself.

[mrkkrp]

Deletion of ~/.stack/snapshots didn't help. stack build works, but Flycheck fails to build anything because of this problem. I have no idea how to continue. Need a break.

Here I can reproduce it on command line manually:

~/projects/programs/haskell/plan-b $ stack ghc -- -Wall -no-link -outputdir /tmp/flycheck-haskell-ghc-cache185895L5 -XHaskell2010 -i/home/mark/projects/programs/haskell/plan-b/dist/build -i/home/mark/projects/programs/haskell/plan-b/dist/build/autogen -i/home/mark/projects/programs/haskell/plan-b/.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build -i/home/mark/projects/programs/haskell/plan-b/.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/autogen -i/home/mark/projects/programs/haskell/plan-b/ -i/home/mark/projects/programs/haskell/plan-b/tests -i/home/mark/projects/programs/haskell/plan-b/ -Wall -hide-all-packages -package base -package exceptions -package hspec -package path -package path-io -package temporary -package transformers -x hs /home/mark/projects/programs/haskell/plan-b/System/PlanB.hs

[1 of 2] Compiling System.PlanB.Type ( System/PlanB/Type.hs, /tmp/flycheck-haskell-ghc-cache185895L5/System/PlanB/Type.o ) [flags changed]
[2 of 2] Compiling System.PlanB     ( /home/mark/projects/programs/haskell/plan-b/System/PlanB.hs, /tmp/flycheck-haskell-ghc-cache185895L5/System/PlanB.o )

/home/mark/projects/programs/haskell/plan-b/System/PlanB.hs:65:47:
    Couldn't match expected type ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Internal.Path
                                    b16 path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.File’
                with actual type ‘Path Abs File’
    NB: ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Internal.Path’
          is defined in ‘Path.Internal’
              in package ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8’
        ‘Path’
          is defined in ‘Path.Internal’
              in package ‘path-0.5.3@path_FF4geOPnhyxDxuXRlWFMak’
    In the first argument of ‘Dir.renameFile’, namely ‘apath’
    In the third argument of ‘liftM2’, namely
      ‘(Dir.renameFile apath fpath)’

<a dozen of similar errors>

[mgsloan]

It might be helpful to delete the system install and do a new stack setup.

I think the main issue is that flycheck is passing -package specifications rather than specific package-ids. Now, this should be fine in theory, path in the snapshot DB should be preferred.

So, I think what's happening is that it's using something out of the global DB which hasn't been compiled with this different path version. Just a guess, though. Has the code that flycheck is trying to use been built by stack? If not, then that would be the explanation - it hasn't had the chance to build this intermediate package between your code and path.

[mrkkrp]

All the code has been built by stack.

It seems like deletion of whole ~/.stack directory and new stack setup do not solve this. The problem persists — this means that it's not some strange configuration I have accidentally created, but something systematic. Not sure why it's become visible only now. Pure mystic.

---

In case someone will want to reproduce it, here is the repo (this is the only project where this “bug” is visible, for some reason):

https://github.com/mrkkrp/plan-b

Clone, build, then if you use Flycheck just open one of source files or run that command I posted earlier (changing paths).

[mrkkrp]

The situation is getting worse (another package):

Could not deduce (exceptions-0.8.0.2:Control.Monad.Catch.MonadThrow
                    m)
  arising from a use of ‘parseAbsDir’
from the context (MonadIO m, MonadThrow m)
  bound by the type signature for
             listDir :: (MonadIO m, MonadThrow m) =>
                        Path b Dir -> m ([Path Abs Dir], [Path Abs File])
  at /tmp/.flycheck96358t/IO.hs:(281,12)-(283,40)
Possible fix:
  add (exceptions-0.8.0.2:Control.Monad.Catch.MonadThrow
         m) to the context of
    the type signature for
      listDir :: (MonadIO m, MonadThrow m) =>
                 Path b Dir -> m ([Path Abs Dir], [Path Abs File])
In the second argument of ‘liftM’, namely ‘parseAbsDir ipath’
In the expression: Left `liftM` parseAbsDir ipath
In a stmt of a 'do' block:
  if isDir then
      Left `liftM` parseAbsDir ipath
  else
      Right `liftM` parseAbsFile ipath

Yet it builds OK with stack build. Is there something I can do about it? Should I try to modify Flycheck to pass package IDs instead of package names (not sure it's easy). Or maybe you can point were to dig in Stack source to make it work?

[mrkkrp]

@mgsloan, I have new thoughts/information about this issue. I thought about your reply about “something out of global DB” and after some painful hours with my workflow broken I noticed that the error message has changed:

Couldn't match expected type ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Internal.Path
                                b0 path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Dir’
            with actual type ‘Path b Dir’
NB: ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8:Path.Internal.Path’
      is defined in ‘Path.Internal’
          in package ‘path-0.5.3@path_IZNE41mKOIkJFz9OWU36V8’
    ‘Path’
      is defined in ‘Path.Internal’
          in package ‘path-0.5.3@path_BuFcQg3iwex0MNhLAdsJ0E’
Relevant bindings include
  dir :: Path b Dir (bound at /tmp/.flycheck14380xx/Zip.hs:143:12)
  unpackInto :: Path b Dir -> ZipArchive ()
    (bound at /tmp/.flycheck14380xx/Zip.hs:143:1)
In the first argument of ‘ensureDir’, namely ‘dir’
In the first argument of ‘liftIO'’, namely ‘(ensureDir dir)’

The second package ID has changed. I started to think what change have I done on my system and it occurred to me that I've upgraded packages on system level. Now, things are getting interesting: I'm using Arch Linux and it has got packages for some Haskell libraries and I think I've got them as dependencies of Stack.

One of the packages is haskell-path. Quick research showed that package ID of the package is:

path-0.5.3@BuFcQg3iwex0MNhLAdsJ0E

This means that this system-level installation is what confuses Flycheck!

Knowing that, is there any easy way to tell stack ghc command that Flycheck uses to… perhaps ignore these system-level installations or otherwise solve this problem?

[mgsloan]

I think this cabal issue may be relevant - haskell/cabal#2830 - this affected me quite recently... (in stack build, not when invoking ghc). I'm not sure if there's anything stack can do about it.

One possible workaround is to keep your global DB as minimal as possible. This is, infact, stack's default. Stuff is never installed to the global DB, just the snapshot DB. So maybe having stack setup ghc, and using that, will fix the problem? (you can still have your system level install, it just won't get used)

[mrkkrp]

I uninstalled haskell-stack package with all its dependencies and built it myself. Now the problem has gone. It's OK for me to run stack upgrade --git periodically, so I think this is an acceptable solution, at least for now.

[mgsloan]

Ah, interesting! Since the problem is resolved, I'm going to go ahead and close this.

[mgsloan]

@mrkkrp It may also be helpful to try out stack ghci --with-ghc flycheck. I haven't tried it, but if flycheck's CLI is a superset of GHC's CLI, should work.

See also #1737

[mrkkrp]

This problem has returned:

Couldn't match expected type ‘http-client-0.4.28@httpc_67tSqXI7MNx0xeSbbxT9Vu:Network.HTTP.Client.Types.Manager’
            with actual type ‘http-client-0.4.28@httpc_KOR3skrgzbXGs0H4TPJO7d:Network.HTTP.Client.Types.Manager’
NB: ‘http-client-0.4.28@httpc_67tSqXI7MNx0xeSbbxT9Vu:Network.HTTP.Client.Types.Manager’
      is defined in ‘Network.HTTP.Client.Types’
          in package ‘http-client-0.4.28@httpc_67tSqXI7MNx0xeSbbxT9Vu’
    ‘http-client-0.4.28@httpc_KOR3skrgzbXGs0H4TPJO7d:Network.HTTP.Client.Types.Manager’
      is defined in ‘Network.HTTP.Client.Types’
          in package ‘http-client-0.4.28@httpc_KOR3skrgzbXGs0H4TPJO7d’
In the fourth argument of ‘rawListing’, namely ‘manager’
In the first argument of ‘runExceptT’, namely
  ‘(rawListing
      True True authData manager (BaseUrl Https host 443 ""))’

This time I do not (to my knowledge) have haskell-http-client installed at all (as a system-level package). One day it worked, then it ceased to work and started to produce the error message shown above. This project that I'm working on has fair number of extra dependencies that I was adding gradually. Is it possible that they introduced this somehow?

---

Also, some time ago I worked on a package where I needed QuickCheck-2.8.2 and snapshots only have QuickCheck-2.8.1 so I went ahead and added it as en extra dependency:

resolver: lts-5.14
packages:
- '.'
extra-deps:
- QuickCheck-2.8.2

This produced rather curious error message from Flycheck:

No instance for (QuickCheck-2.8.1:Test.QuickCheck.Property.Testable
                   Property)
  arising from a use of ‘testProperty’
In the expression:
  testProperty "monoid left identity" prop_monoid_left_id
In the second argument of ‘testGroup’, namely
  ‘[testProperty "monoid left identity" prop_monoid_left_id,
    testProperty "monoid right identity" prop_monoid_right_id,
    testProperty "monoid associativity" prop_monoid_assoc,
    testProperty "consistency of Show/Read" prop_showReadConsistency,
    ....]’
In the expression:
  testGroup
    "Parse errors"
    [testProperty "monoid left identity" prop_monoid_left_id,
     testProperty "monoid right identity" prop_monoid_right_id,
     testProperty "monoid associativity" prop_monoid_assoc,
     testProperty "consistency of Show/Read" prop_showReadConsistency,
     ....]

Extra-deps do not has any effect on Flycheck. Not sure that these problems are related, though.