Skip to content
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
Closed

Stack ghci should load intermediate dependencies #584

hesselink opened this issue Jul 14, 2015 · 9 comments

Comments

@hesselink
Copy link
Contributor

@hesselink 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
Copy link
Member

@chrisdone 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
Copy link
Member

@chrisdone chrisdone commented Jul 14, 2015

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

@hesselink
Copy link
Contributor Author

@hesselink 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
Copy link
Member

@chrisdone 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
Copy link
Member

@bergmark bergmark commented Jul 16, 2015

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

@mgsloan
Copy link
Contributor

@mgsloan 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
Copy link
Contributor Author

@hesselink 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
Copy link
Contributor

@mgsloan 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
Copy link
Contributor Author

@hesselink 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants