How to use custom prelude with stack ghci? - haskell

I added a custom Prelude, which is working well for stack build and stack test. However, stack ghci does not like it, as it seems to be trying to load all of these at once:
$ stack --nix ghci
XXX-0.1.0.0: initial-build-steps (lib + exe)
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: XXX
* * * * * * * *
Error: Multiple files use the same module name:
* Prelude found at the following paths
* XXX/server/Prelude.hs (XXX:exe:XXX.exe)
* XXX/src/Prelude.hs (XXX:lib)
* XXX/tests/Prelude.hs (XXX:exe:tests.exe)
* * * * * * * *
Not attempting to start ghci due to these duplicate modules.
First, to explain the three different Prelude.hs files: they are identical as two of them are symbolic links to the third file; I hadn't thought of a better way to do this without possibly exposing my Prelude.hs to dependent libraries.
A possible workaround would be to tell stack/ghci to only load the library code (under src in this case), or better yet, be able to tell it to skip particular .hs files on loading.

Related

Multiple files use the same module name:

when I type stack run I get no error message but when I type stack ghci I get this error about multiple files use the same name , how I can solve it ?
(base) wejden#wejdenaydi:~/wejden$ stack ghci
Using main module: 1. Package `wejden' component wejden:exe:wejden-exe with main-is file: /home/wejden/wejden/app/Main.hs
Building all executables for `wejden' once. After a successful build of all of them, only specified executables will be rebuilt.
wejden> configure (lib + exe)
Configuring wejden-0.1.0.0...
wejden> initial-build-steps (lib + exe)
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: wejden
* * * * * * * *
Warning: Multiple files use the same module name:
* Paths_wejden found at the following paths
* /home/wejden/wejden/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/autogen/Paths_wejden.hs (wejden:lib)
* /home/wejden/wejden/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/wejden-exe/autogen/Paths_wejden.hs (wejden:exe:wejden-exe)
* * * * * * * *
GHCi, version 8.10.4: https://www.haskell.org/ghc/ :? for help
[1 of 3] Compiling Lib ( /home/wejden/wejden/src/Lib.hs, interpreted )
[2 of 3] Compiling Main ( /home/wejden/wejden/app/Main.hs, interpreted )
[3 of 3] Compiling Paths_wejden ( /home/wejden/wejden/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/autogen/Paths_wejden.hs, interpreted )
Ok, three modules loaded.
Loaded GHCi configuration from /tmp/haskell-stack-ghci/f99925e2/ghci-script
*Main Lib Paths_wejden>
For those who, like me, need very specific instructions, here it goes:
executables:
mypkgname-exe:
main: Main.hs
source-dirs: app
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- stocks
when:
- condition: false
other-modules: Paths_mypkgname
where mypkgname needs to be replaced with your package name. I'm posting this because on my first attempt I had put the when clause in the wrong place.
This is a known issue with hpack: https://github.com/commercialhaskell/stack/issues/5439
In short, add this in your package.yaml, to your executable(s) or your library:
when:
- condition: false
other-modules: Paths_wejden # your package name here

ghci: module ‘main:Main’ is defined in multiple files - in new small stack init build ghci package

I try to setup a stack based Haskell IDE with vscode and start with a small project created with stack init and then added a second module in src and added some dependencies in package.yaml. It builds ok but when I start stack ghci I have warnings:
Warning: Multiple files use the same module name:
* Paths_primo found at the following paths
* /home/frank/Workspace11/primo/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/autogen/Paths_primo.hs (primo:lib)
* /home/frank/Workspace11/primo/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/primo-exe/autogen/Paths_primo.hs (primo:exe:primo-exe)
* * * * * * * *
GHCi, version 8.10.4: https://www.haskell.org/ghc/ :? for help
[1 of 3] Compiling Lib ( /home/frank/Workspace11/primo/src/Lib.hs, interpreted )
[2 of 3] Compiling YamlRead ( /home/frank/Workspace11/primo/src/YamlRead.hs, interpreted )
[3 of 3] Compiling Main ( /home/frank/Workspace11/primo/app/Main.hs, interpreted )
Ok, three modules loaded.
There seems to be a confusion with autogen and with Paths_primo (primo is the name of the package). What am I doing wrong?
General question: what is the correct way to clean a stack project to "start over" after some experimentation? Is is correct to delete the cabal file and the stack-work directory. Waht is with stack.yaml and 'stack.yaml.lock`?
This appears to be a harmless warning reported at Stack issue #5439, whose underlying cause is hpack issue #303. A workaround to get rid of the warning is disabling the generation of the Paths_ module for your primo-exe executable, by adding the following to its section in package.yaml:
when:
- condition: false
other-modules: Paths_primo

Stack is unable to resolve the correct package version

I am trying to use grenade in Haskell. Using stack as a configuration tool, I have
# stack.yaml
extra-deps:
- diagrams-solve-0.1.1
- dual-tree-0.2.2
- SVGFonts-1.6.0.3
- diagrams-core-1.4.1
- diagrams-lib-1.4.2.2
- diagrams-postscript-1.4.1
- diagrams-svg-1.4.2
- Chart-diagrams-1.8.3
- hip-1.5.3.0
- singletons-2.2
- template-haskell-2.11.1.0
- th-desugar-1.6
- grenade-0.1.0
But when I execute stack build, it gives me the following error
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for th-desugar-1.6:
template-haskell-2.12.0.0 from stack configuration does not match <2.12 (latest
matching version is 2.11.1.0)
needed due to Brain-0.1.0.0 -> th-desugar-1.6
Some different approaches to resolving this:
* Set 'allow-newer: true' to ignore all version constraints and build anyway.
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to
find some working build configuration. This can be convenient when dealing with
many complicated constraint errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps
in [Project directory]/stack.yaml:
- template-haskell-2.11.1.0
Plan construction failed.
Even if I put - template-haskell-2.11.1.0 before diagrams-solve, stack still gives me the same error. Allowing newer versions is not viable since it breaks th-desugar.
That looks like a lot of extra-deps. I'd recommend figuring out a good resolver first. The best way to do that is use the original repo:
git clone git#github.com:HuwCampbell/grenade.git
cd grenade
stack init
Which gives you the following output:
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- ./
- examples/
Selecting the best among 13 snapshots...
* Partially matches lts-11.13
criterion version 1.3.0.0 found
- grenade requires ==1.1.*
Downloaded nightly-2018-06-16 build plan.
* Partially matches nightly-2018-06-16
criterion version 1.4.1.0 found
- grenade requires ==1.1.*
hmatrix version 0.19.0.0 found
- grenade requires ==0.18.*
- grenade-examples requires ==0.18.*
singletons version 2.4.1 found
- grenade requires >=2.1 && <2.4
* Partially matches lts-10.10
criterion version 1.2.6.0 found
- grenade requires ==1.1.*
Downloaded lts-9.21 build plan.
* Matches lts-9.21
Selected resolver: lts-9.21
Initialising configuration using resolver: lts-9.21
Total number of user packages considered: 2
Writing configuration to file: stack.yaml
All done.
So use the base resolver lts-9.21. And I'd open an issue on the repo of grenade to add it to stack.

How do I add a CPP defininition within cabal / stack?

I'm looking at the following module: https://hackage.haskell.org/package/boxes-0.1.4/docs/src/Text-PrettyPrint-Boxes.html
Which has contents of:
module Text.PrettyPrint.Boxes
( -- * Constructing boxes
#ifdef TESTING
Box(Box, content)
#else
Box
#endif
How can I enable / define the TESTING value - for development purposes? Ideally I'd like to have this built / enabled within a GHCi session.
I have to correct myself - the comment I gave is totally and utterly wrong.
> git clone git://github.com/treeowl/boxes.git
> cd boxes
> stack init
> stack ghci --ghc-options=-DTESTING
split-0.2.3.2: using precompiled package
boxes-0.1.4: configure (lib)
Configuring boxes-0.1.4...
boxes-0.1.4: initial-build-steps (lib)
Completed 2 action(s).
Configuring GHCi with the following packages: boxes
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from ...
[1 of 1] Compiling Text.PrettyPrint.Boxes ( .../boxes/Text/PrettyPrint/Boxes.hs, interpreted )
Ok, modules loaded: Text.PrettyPrint.Boxes.
Loaded GHCi configuration from /tmp/ghci28386/ghci-script
*Text.PrettyPrint.Boxes Text.PrettyPrint.Boxes> :t content
content :: Box -> Content
just works fine.

Should stack repl load test modules from *other* packages?

I have a project which pulls in two local packages. My stack.yaml has:
packages:
- '.'
- '../creatur-wains'
- '../creatur-wains-test-utils'
Both creatur-wains and creatur-wains-test-utils define a module called ALife.Creatur.Wain.TestUtils, but in creatur-wains it's only part of the test code, not part of the library. This wasn't a problem when I was using ghci. I could load both packages, and only the version of TestUtils from creatur-wains-test-utils was visible.
However, Stack also seems to pull in the test modules from creatur-wains, so I get the following error:
$ stack repl
The following GHC options are incompatible with GHCi and have not been passed to it: -Werror -threaded
Configuring GHCi with the following packages: creatur-dvector-wains, creatur-wains-test-utils, creatur-wains
* * * * * * * *
The following modules are present in multiple packages:
* ALife.Creatur.Wain.TestUtils (in creatur-wains, creatur-wains-test-utils)
* * * * * * * *
Not attempting to start ghci due to these duplicate modules.
Use --no-load to try to start it anyway, without loading any modules (but these are still likely to cause errors)
I can work around this using --no-load, and adding the packages one by one, but that's a bit tedious. Is this desireable behaviour for stack repl, or is it a bug?
From the stack ghci docs (https://docs.haskellstack.org/en/stable/ghci/):
Similarly to stack build, the default is to load up ghci with all libraries and executables in the project.
So, to load just one package you need to do stack ghci creatur-wains.

Resources