stack repl confused by locally unpacked hackage lib

[robinp]

Just asking if you know about this, or have a quick idea on fixing. Can provide details/repro later if not.

I have in stack.yaml (with various resolvers, for example 11.7)

packages:
- .
- gloss-rendering-1.11.1.1
- gloss-1.11.1.1

where the gloss-* dirs were unpacked with stack unpack.

The project builds and runs fine. But when attempting stack repl, it seems to confuse the source-based one with the library:

    * Couldn't match type `gloss-rendering-1.11.1.1:Graphics.Gloss.Internals.Data.Picture.Picture'
                     with `Picture'
      NB: `Picture' is defined at
            ...path..to...............\gloss-rendering-1.11.1.1\Graphics\Gloss\Internals\Data\Picture.hs:(63,1)-(124,43)
          `gloss-rendering-1.11.1.1:Graphics.Gloss.Internals.Data.Picture.Picture'
            is defined in `Graphics.Gloss.Internals.Data.Picture'
                in package `gloss-rendering-1.11.1.1'
      Expected type: Maybe Picture
        Actual type: Maybe
                       gloss-rendering-1.11.1.1:Graphics.Gloss.Internals.Data.Picture.Picture

Not sure for the reason. Thank you.

[robinp]

I tried to put the unpacked dirs outside of the source tree, but doesn't make a difference. It sounds like the original cabal package gets into ghci's package db too.

[robinp]

Found the issue: I also depend on gloss-juicy, which in turn depends on gloss. So while the unpacked gloss got passed to GHCi by source path (using -i<the unpacked path>), gloss-juicy is passed by its package-id, and naturally it's pkgdb file references gloss by package-id as well. This led to gloss being pulled in twice.

Workaround: unpack all dependencies used as well (here gloss-juicy).

It would be nice if stack gave a warning about this situation at least.

[robinp]

Actually this behavior gets cumbersome as more unpacked package deps are added. It would be nice to be able to control which of those get expanded by source for GHCi, and which keep to get passed by package id.