Reload cabal file from stack ghci? - haskell

If I modify my cabal file to add a module, :reload doesn't pick that up. Is there a way to :reload as if I ran stack ghci anew without having to exit ghci?

Related

Can I persuade stack / ghci to *only* load the local .ghci file?

I have a .ghci in my local project directory, and another one in my $HOME. When I do a stack ghci, then $HOME/.ghci is loaded first, followed by $PWD/.ghci. Is it possible to have ONLY the local .ghci be loaded, and the global one ignored?
I could do a stack exec -- ghci -ignore-dot-ghci, but then, none is loaded.
What I also tried is:
stack exec -- ghci -ignore-dot-ghci -W .ghci
The idea being to first tell ghci not to load anything and then explicitly requesting the local .ghci file, but this gives the error message Warning: ignoring unrecognised input `.ghci'
GHCi has a -ghci-script flag which can be used alongside -ignore-dot-ghci. It can be used with stack ghci through --ghci-options:
stack ghci --ghci-options "-ignore-dot-ghci -ghci-script .ghci"
For the sake of completeness, here is the corresponding cabal repl invocation:
cabal repl --repl-options "-ignore-dot-ghci" --repl-options "-ghci-script .ghci"

What is the cabal equivalent of `stack ghci app:exe:executable`?

I've previously used stack ghci app:exe:executable to get a list of any errors in my Haskell project managed via cabal.
However now that I'm not using stack, how would I achieve the above (essentially load all the modules from the executable defined in the cabal project file)?
https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-repl
cabal v2-repl executableNameGoesHere

Both versions of the gtk package are visible when running `stack ghc`

A minimal reproduction can be found here:
https://github.com/IvanMalison/stack-gtk2hs-bug
Everything works as expected when I use normal stack commands, but when I run the failing command:
stack ghc -- --make main.hs
I get the following error:
main.hs:3:1: error:
Ambiguous interface for ‘Graphics.UI.Gtk’:
it was found in multiple packages: gtk-0.14.6 gtk3-0.14.6
main.hs:4:1: error:
Ambiguous interface for ‘Graphics.UI.Gtk.Abstract.Widget’:
it was found in multiple packages: gtk-0.14.6 gtk3-0.14.6
main.hs:5:1: error:
Ambiguous interface for ‘Graphics.UI.Gtk.Layout.Table’:
it was found in multiple packages: gtk-0.14.6 gtk3-0.14.6
The output of stack exec ghc-pkg -- --no-user-package-db list is https://gist.github.com/f19f900988f49e4d03cd61f1cab48baa . This output makes me expect that the reason that this is happening is that some other stack install required gtk (not gtk3 which is what is specified as a dependency in this package) and somehow this package is visible from the stack ghc command for some reason.
Am I misunderstanding the stack ghc command? Shouldn't this essentially do the same thing as stack build?
There's no builtin way to do this with stack currently. However, it is possible to get stack ghci to do this. The most straightforward way to do it is to make a cabal package which has the executable target. However, if you really want to just use straight ghc, there is a way. Copy-pasting from my comment here:
stack ghc works a bit differently than stack ghci. It's essentially a synonym for stack exec -- ghc, which will run the right compiler with the right databases, but won't set up anything related to your local packages like include directories etc. Note that stack ghci takes TARGET arguments whereas stack ghc does not. Retrospectively, this is a bit inconsistent, but stack ghc came before stack ghci.
It does make sense to have the ability to do something like this, though not sure how to best achieve that. Some potential options:
--no-interactive argument on stack ghci. Would be a bit obtuse. Weird to run a ghci command when, though it would be using the stack ghci logic.
Add --target TARGET option to stack ghc, to tell it to use the environment of a particular local package target.
Here's a workaround for now. Put the following in ~/.local/bin/stack-run-ghc.sh and make it user executable:
#/bin/sh
ghc $(echo "$*" | sed 's/--interactive//g')
This takes the arguments, removes --interactive, and calls ghc. With this, I can build stack using ghc via the following:
stack ghci --with-ghc stack-run-ghc.sh --ghci-options src/main/Main.hs

How to load tests in ghci with stack

I created a very simple project with stack. It contains: an executable, a library and test targets in the associated cabal file. When I load the code to ghci via stack ghci, I can't access test there, even if they are in separate module. Is there any way to use it in such a way?
Try stack ghci (your project name):(the test suite name). Then you should be able to enter main and your tests will run.
Example:
If your .cabal project file had the following values:
name: ExampleProject
...
test-suite Example-test
Then the command to run would be stack ghci ExampleProject:Example-test
(edit suggested by #Chris Stryczynski)
To watch the test and src directories so they are updated when you reload with :r, run:
stack ghci --ghci-options -isrc --ghci-options -itest ExampleProduct:Example-test

stack ghci not loading up local modules?

I have
mainLogger.hs
Logger.hs
in my local directory where the mainLogger.hs reference the Logger module.
When in stack ghci I :load mainLogger.hs I get the following error message :
mainLogger.hs:6:18:
Could not find module ‘Logger’
It is not a module in the current program, or in any known package.
However if I can compile stack exec -- ghc mainLogger.hs and run stack runghc mainLogger2.hs or have stack exec -- ghci load the module correctly.
Anyone knows what is preventing stack ghci from locating module in the local directory ?
ps : I am not using any cabal file or stack.yaml file in this directory, so it falls back onto my global stack.yaml config
You should be able to load both if you do it at the same time:
:load Logger.hs mainLogger.hs
I don't know if you can get GHCi to look for the missing module in the current folder if you have no cabal file but if you create/initialize one this is not necessary.
This issue should now be fixed in the latest version of stack. It seems that when a module imported a local module, stack wasn't including the local directory in its module search path. In the latest 1.5.1. version of stack, this has been fixed - so you should be able to just type
stack ghci mainLogger.hs

Resources