Stack ghci should load intermediate dependencies

[hesselink]

I often have scenarios where I'm changing two packages (A and C) and I'd like to load them into ghci together. However, there is a third package (B) in between, so that B depends on C, and A depends on B and C. Now, when I do stack ghci A C I will get weird errors:

    Couldn't match type ‘T’
                  with ‘T’
    NB: ‘T’
          is defined in ‘Types.T’
              in package ‘C-0.14.3’
        ‘T’ is defined at
          /my/sources/C/src/Types/T.hs:(36,1)-(49,28)

This is because package B is loaded from the installed library, depending on the installed C, whereas A is using C interpreted. So we have two definitions of type T which are not compatible.

My ideal solution would be if stack ghci A C would also interpret (and not use as a package) all the intermediate dependencies between A and C that are available in the project.

[chrisdone]

Good use-case. This makes sense. If you'd only requested ghci A then it would be acceptable to load B and C from library, but because you want to load C from source, so too should B be loaded. I think this should be more or less straight-forward, we have all the data.

[chrisdone]

Should note for other readers that the workaround is to specify stack ghci A B C manually.

[hesselink]

Yes, but that quickly becomes annoying if the dependencies grow :) I just stack ghci C only, then stack build A, then stack ghci A. For people with smaller projects, stack ghci without arguments is of course also a good option, but that's too slow for me.

[chrisdone]

Of course, it's a workaround, not a solution. ;-)

[bergmark]

A million +1's, that's +1000000

[mgsloan]

Done!

I've opened a separate issue for handling the case where these intermediate dependencies are non-local packages: #1441

[hesselink]

Great! I just installed and it seems to work very well on my first tests. This is going to make my development workflow much smoother.

One thing I noticed is that it will still try to build the packages it's loading if they've changed. You can pass --no-build to skip that, but maybe that should be the default? I can't see any reason anymore to build those packages.

[mgsloan]

The reason those are built is to ensure that autogenerated files are updated. Removing this default is covered in #1364

[hesselink]

Great, thanks!