-
Notifications
You must be signed in to change notification settings - Fork 175
Package resolution failure on test executables #635
Comments
Yeah we use an ugly workaround to get the tests to work: https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/Cradle.hs#L46 This is because some of the tests assume a plain (i.e. non cabal) environment but since there is a .cabal file up the directory hierarchy for the tests ghc-mod thinks they are part of a cabal project. |
I think it's little more than that. Sometimes tests require their own packages which are spelled out in the .cabal file and not just a plain setup. For example in an empty project with a test executable which depends on name: example
version: 0.1.0.0
build-type: Simple
library
exposed-modules:
Example
build-depends:
base >=4.7 && < 5
test-suite test
type:
exitcode-stdio-1.0
main-is:
Tests.hs
build-depends:
base >= 4 && < 5,
tasty >= 0.10 && < 0.12 |
Aha, this seems to happen only when one is using stack. Without knowing any of the details, I'd take a guess at the cause being that stack is a little more careful about where it installs packages, and which of them are visible to whom. |
Any update on this? I have a same issue when using with |
@noraesae, running |
How does stack even handle tests? The problem is that in cabal there is a flag to turn them on as @expipiplus1 said but how does stack decide to enable tests in the generated configuration? My guess was always just doing Alternatively look at the I think you'll want to look at |
Okay so it looks like this comes down to ghc-mod configuring a stack project using cabal-install when it shouldn't and then sticking to cabal-install once dist/setup-config exists. I managed to get it to work by deleting |
In Emacs you can enable verbose logging: |
Running ghc-mod on its own test code fails, as it doesn't see the correct packages:
Running
ghc-mod info src/GHCMod.hs foo
has the correct behaviour, but runningghc-mod info test/Main.hs foo
fails because the packages aren't being made visible.As far as I can tell, ghc-mod isn't compiling the files with the packages (and other attributes) they are listed with in the .cabal file, instead it's always using the packages from the primary executable or library.
The text was updated successfully, but these errors were encountered: