Set HASKELL_PACKAGE_SANDBOX environment variable

[snoyberg]

This is related to a few other issues in other projects: commercialhaskell/stackage#3 sol/doctest#39 faylang/fay#174

There are some packages which make use of the package database themselves. Fay calls GHC for type checking, doctest calls it to test code snippets, and there are likely others. This works fine when using the standard user package database, but when using a sandbox such as created by cabal-dev, this no longer works.

The solution we came up with for Stackage was to set a HASKELL_PACKAGE_SANDBOX environment variable. doctest now recognizes it, and in theory Fay can do so as well. I think it would make sense for cabal-dev to set this variable as well.

Note that this is similar to GHC_PACKAGE_PATH, but works around the fact that cabal-install will not allow that variable to be set.

Pinging @sol @chrisdone and @jwiegley who have each been affected by this somehow.

[jwiegley]

Michael Snoyman notifications@github.com writes:

Pinging @sol @chrisdone and @jwiegley who have each been affected by this
somehow.

I updated and ran the build again, but I'm still seeing that same test failure in
conduit:

--8<---------------cut here---------------start------------->8---
Data/Conduit.hs:79:8:
Could not find module `Data.Void'
Perhaps you meant
Data.Word (from base)
Data.Word (needs flag -package haskell2010-1.1.0.1)
Use -v to see a list of the files searched for.
Test suite doctests: FAIL
--8<---------------cut here---------------end--------------->8---

John Wiegley
FP Complete Haskell tools, training and consulting
http://fpcomplete.com johnw on #haskell/irc.freenode.net

[snoyberg]

It's because the new doctest isn't on Hackage.

[sol]

There are some issues that I have to resolve. I'm working on it, sorry for the delay.

[sol]

doctest-0.9.4 has support for HASKELL_PACKAGE_SANDBOX.

[sol]

Would it make sense to set GHC_PACKAGE_PATH before running the tests, instead?

Similar to commercialhaskell/stackage@2534579.

[snoyberg]

That change would probably have to take place in cabal-install instead, as I think it calls all of the tests itself.

[sol]

@snoyberg Ah ok, I see what you mean. cabal-dev does not wrap the commands individually, so there is currently no easy way to tell whether it's cabal-dev test.