Home/ Questions/Q 6645123
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T00:14:51+00:00

I’m trying out cabal-dev for a project I’m working on; the project is a

  • 0

I’m trying out cabal-dev for a project I’m working on; the project is a library, and cabal-dev does a great job of building a sandboxed version of it – but I’m having trouble with part of my workflow…

I have a script, scratch.hs, which (pre-cabal-dev) I would load into ghci for trying stuff out. The contents of scratch.hs change over time depending on what feature I’m working on, of course. scratch.hs isn’t part of the library codebase, it’s just my personal scratchspace while I’m working on it.

Now, in order to get a ghci session with my sandbox loaded, I can just cabal-dev ghci, and then load scratch.hs into that. The problem is that this (by design, and sensibly) excludes my user package database, so if scratch.hs references modules from packages which aren’t in my library’s build-depends (which is not unreasonable – it’s not part of the library after all), those packages aren’t visible, and so I get an error such as:

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 is not in my library’s build-depends (quite properly), but is in my user package database.

So how can I work around this? I can imagine answers in either of these categories, but maybe there are categories I’ve missed:

  1. A way to (selectively) use packages from my user package database in conjunction with the sandbox created by cabal-dev. (Perhaps rolling my own cabal-dev ghci style script?)

  2. A suggestion on how to improve my workflow so the problem just goes away.

I know I could just install the package globally, but I’m reluctant to pollute my global package database in this manner (and cabal-dev discourages this explicitly).

Many thanks for all advice.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think the simplest solution is just to install the things that 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 that’s inadequate, you have a lot of dependencies you want to use from your user package database, and you don’t need ghci to be invoked with the other flags that your cabal file sets for invoking ghc, then you can invoke non-sandboxed ghci with access to the packages from the sandbox as well as your user and global packages. For example (for GHC 7.0.3):

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

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

    • 0