hspec-1.4.2.2 test suite fails about stackage

[snoyberg]

Pinging @sol. I don't have this problem, but @jwiegley reported something similar. Any ideas Simon?

[sol]

This is probably again ghc not finding sandbox packages. @snoyberg I guess you don't have this problem, because you installed setenv outside your sandbox.

I think the general solution would really be to set GHC_PACKAGE_PATH before running the test suites.

@snoyberg you mentioned some complications with cabal (or cabal-dev here?). If patching cabal-dev is not viable, would it still work to only build the test suites with cabal-dev but run them ourself?

[sol]

If nothing else helps, I can of course somehow special-case this particular test case ;)

(BTW: The affected test case does not really test Hspec, rather a precondition it relies on.)

[snoyberg]

The problem is with cabal-install itself. If you try to set GHC_PACKAGE_PATH, it fails...

But I just checked, and GHC_PACKAGE_PATH=foo: cabal test seems to work. Let me test this a little further.

[snoyberg]

Alright, by removing setenv from my user package repo I was able to reproduce the error, and with the attached commit was able to resolve it. Can you test this and let me know if it works for you?

[sol]

@snoyberg It would be possible to use GHC_PACKAGE_PATH instead of HASKELL_PACKAGE_SANDBOX in doctest, right?

[snoyberg]

It still wouldn't work for the case of cabal-dev install hspec --enable-tests, since in that case you can't use GHC_PACKAGE_PATH. I'm still confused as to why the HASKELL_PACKAGE_SANDBOX didn't solve this problem entirely, do you know why not? IMO it's still the more resilient solution.

[sol]

Because this is not related to doctest.

[snoyberg]

Oh, the hspec test suite is calling GHCi itself directly?

[sol]

Yes, it is to make sure that future versions of ghci keep changes to env.

[snoyberg]

Got it, makes sense. Sorry for the mistaken assumption about hspec.

[sol]

np ;)

[snoyberg]

This test suite should now build. Please reopen issue if problem reappears.