Cómo usar "cabal-dev ghci" con un paquete no sandbox, no global (¿usuario?)?

Question

Estoy probando cabal-dev para un proyecto en el que estoy trabajando; el proyecto es una biblioteca y cabal-dev hace un gran trabajo de construir una versión de un recinto de seguridad de la misma - pero estoy teniendo problemas con parte de mi flujo de trabajo ...

Tengo un script, scratch.hs, que (pre cabal-dev) Me gustaría cargar en ghci para probar cosas. Los contenidos de scratch.hs cambian con el tiempo dependiendo de la función en la que estoy trabajando, por supuesto. scratch.hs no es parte de la base de código de la biblioteca, es solo mi espacio personal mientras estoy trabajando en él.

Ahora, para obtener una sesión ghci con mi sandbox cargado, puedo simplemente cabal-dev ghci, y luego cargar scratch.hs en eso. El problema es que esto (por diseño y sensiblemente) excluye mi base de datos de paquetes de usuario, por lo que si scratch.hs hace referencia a módulos de paquetes que no están en el build-depends de mi biblioteca (que no es irracional, después de todo no es parte de la biblioteca), paquetes no son visibles, y así me sale un error como:

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. 

donde, en este caso, scratch.hs quiere importar Data.Aeson.Generic pero aeson no está en mi biblioteca build-depends (bastante correctamente), pero es en mi base de datos de paquetes de usuario.

Entonces, ¿cómo puedo evitar esto? Me puedo imaginar respuestas en cualquiera de estas categorías, pero tal vez hay categorías que he perdido:

1. una manera de (selectivamente) utilizar los paquetes de mi base de datos de paquete de usuario en combinación con la caja de arena creado por cabal-dev. (Tal vez rodando mi propio script de estilo cabal-dev ghci?)

2. Una sugerencia sobre cómo mejorar mi flujo de trabajo por lo que el problema simplemente desaparece.

sé que sólo pudiera instalar el paquete en todo el mundo, pero me resisto a contaminar mi base de datos del paquete global en esta manera (y cabal-dev desalienta esto explícitamente).

Muchas gracias por todos los consejos.

Answer 1

Creo que la solución más simple es simplemente instalar las cosas que necesita en la caja de arena. Por ejemplo, si necesita Aeson para su script interactivo:

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

Entonces :set -package aeson debe trabajar en ghci.

Si eso es inadecuada, que tienen un gran número de dependencias que desea utilizar desde su base de datos de paquete de usuario, y usted no necesita ghci que se invoca con las otras banderas que sus conjuntos de archivos de Cabal para invocar ghc, entonces se puede invoque ghci sin espacio aislado con acceso a los paquetes del entorno limitado, así como a su usuario y paquetes globales. Por ejemplo (para GHC 7.0.3):

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

(Nota tanto los dos puntos al final de la GHC_PACKAGE_PATH y el espacio entre eso y ghci.)