How to use "cabal-dev ghci" with a non-sandbox, non-global (user?) Package?

Question

I am testing cabal-dev for a project that I am working on; the project is a library, and cabal-dev does an excellent job of creating an isolated version, but I'm having problems with part of my workflow ...

I have a script, scratch.hs , which ( cabal-dev ) I would upload to ghci for testing. The contents of scratch.hs change over time depending on which function I work with, of course. scratch.hs not part of the library codebase, it's just my personal space when I work on it.

Now, to get a ghci session with a sandbox loaded, I can just cabal-dev ghci and then load scratch.hs into this. The problem is that this (by design and reasonably) excludes my database of custom packages, so if scratch.hs refers to modules from packages that are not in my build-depends library (which is not unreasonable - it is not part of the library after everything), these packages are not visible, and therefore I get an error message, for example:

 scripts/scratch.hs:8:8: Could not find module `Data.Aeson.Generic': It is a member of the hidden package `aeson-0.3.2.11'. Perhaps you need to add `aeson' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Failed, modules loaded: none. 

where in this case scratch.hs wants to import Data.Aeson.Generic , but aeson not in my build-depends library (quite correctly), but is in my user package database.

So how can I get around this? I can submit answers in any of these categories, but there may be categories that I skipped:

• A way to (selectively) use packages from the database of my custom package along with the sandbox created by cabal-dev . (Perhaps flip my own cabal-dev ghci script style?)

• A suggestion on how to improve my workflow so that the problem just disappears.

I know that I can just install a package around the world, but I am reluctant to pollute my global package database this way (and cabal-dev speaks explicitly about it).

Thanks so much for the advice.

Answer 1

I think the simplest solution is to simply install what you need into the sandbox. For example, if you need aeson for your interactive script:

 ~/myproject$ cabal-dev install aeson ~/myproject$ cabal-dev ghci 

Then :set -package aeson should work in ghci .

If this is inadequate, you have many dependencies that you want to use from the database of your custom package, and you do not need ghci call ghci with other flags that your cable files set to call ghc , then you can call the non-sandbox ghci with access to packages from the sandbox, as well as to your custom and global packages. For example (for GHC 7.0.3):

 ~/myproject$ GHC_PACKAGE_PATH=./cabal-dev/packages-7.0.3: ghci 

(Note the colon at the end of GHC_PACKAGE_PATH and the space between it and ghci .)