doctest build failures when no non-sandboxed package is installed

[snoyberg]

Pinging @sol on this.

I'm trying to automate a bunch of tests of Hackage. The installation of packages always takes place in a sandbox. Unfortunately, this means that the doctest-based tests do not run:

Test suite doctests: RUNNING...

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
Test suite logged to: dist/test/conduit-0.5.5-doctests.log
Test suite test: RUNNING...
Test suite test: PASS
Test suite logged to: dist/test/conduit-0.5.5-test.log
1 of 2 test suites (1 of 2 test cases) passed.

Is there some way to specify the location of the sandbox to doctest so that it can use it for testing?

[sol]

doctest behaves as GHC/GHCi in that regard. So you would need to pass the same flags to doctest as you would pass to ghci.

One issue that I can imagine is, that you need to modify any package for this to work (and maybe even that those packages then only work with cabal-dev, not sure?).

If it makes sense, we could add better support to doctest for this. Does cabal-dev set any environment variables?

[snoyberg]

I don't think cabal-dev sets environment variables, but I'm not using cabal-dev in any event. How about letting doctest recognize DOCTEST_PACKAGE_PATH as a colon (or on Windows, semi-colon) separate list of package databases, the same as GHC_PACKAGE_PATH (http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/packages.html)?

[sol]

Ah ok, I got that wrong. I thought you were using cabal-dev.

Or just use GHC_PACKAGE_PATH, not sure?

[snoyberg]

Unfortunately, cabal-install won't work if the GHC_PACKAGE_PATH variable is set, and we need to run everything via cabal-install. It's also why I prefer an environment variable to a command-line argument.

[sol]

Is it, that cabal install does not accept --test-option? My first thought was "this is a bug".

If so, I guess an environment variable is the way to go.

[snoyberg]

Ahh, I was not aware of that. Still, an environment variable might be a safer approach. I can always set such a variable without worrying that a non-doctest test suite will choke on it, whereas command line arguments could confuse others.

[sol]

Yes, that's a valid point.

The main difference is of course that command line flags already work, while an environment variable needs work on my part.

But yes, open a ticket ;). I may look into it right away.