New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack ghci should load intermediate dependencies #584

Closed
hesselink opened this Issue Jul 14, 2015 · 9 comments

Comments

Projects
None yet
6 participants
@hesselink
Contributor

hesselink commented Jul 14, 2015

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

This comment has been minimized.

Member

chrisdone commented Jul 14, 2015

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 chrisdone self-assigned this Jul 14, 2015

@chrisdone

This comment has been minimized.

Member

chrisdone commented Jul 14, 2015

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

@hesselink

This comment has been minimized.

Contributor

hesselink commented Jul 14, 2015

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

This comment has been minimized.

Member

chrisdone commented Jul 14, 2015

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

@snoyberg snoyberg added this to the GHCi milestone Jul 14, 2015

@bergmark

This comment has been minimized.

Member

bergmark commented Jul 16, 2015

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

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 28, 2015

Done!

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

@mgsloan mgsloan closed this Nov 28, 2015

@hesselink

This comment has been minimized.

Contributor

hesselink commented Nov 28, 2015

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

This comment has been minimized.

Collaborator

mgsloan commented Nov 30, 2015

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

@hesselink

This comment has been minimized.

Contributor

hesselink commented Nov 30, 2015

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment