Come utilizzare "cabal-dev ghci" con un pacchetto non-sandbox, non globale (utente?)?

Question

Sto provando cabal-dev per un progetto su cui sto lavorando; il progetto è una libreria, e cabal-dev fa un grande lavoro di costruzione di una versione sandbox di esso - ma sto avendo problemi con una parte del mio flusso di lavoro ...

Ho uno script, scratch.hs, che (pre cabal-dev) Vorrei caricare in ghci per provare cose. I contenuti di scratch.hs cambiano nel tempo a seconda di quale funzione sto lavorando, ovviamente. scratch.hs non fa parte della base di codice della libreria, è solo il mio spazio personale mentre sto lavorando su di esso.

Ora, per ottenere una sessione ghci con sandbox caricato, posso solo cabal-dev ghci e quindi caricare scratch.hs in quello. Il problema è che questo (dal design e sensibilmente) esclude il mio database di pacchetti utente, quindi se scratch.hs fa riferimento a moduli da pacchetti che non sono nella libreria build-depends (che non è irragionevole - non fa parte della libreria dopo tutto), quelli pacchetti non sono visibili, e così ottengo un errore come ad esempio:

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. 

in cui, in questo caso, scratch.hs vuole importare Data.Aeson.Generic ma aeson non è nella mia libreria build-depends (giustamente), ma è nel mio database dei pacchetti utente.

Quindi, come posso aggirare questo? Posso immaginare risposte in una di queste categorie, ma forse ci sono categorie che ho perso:

1. un modo per (selettivamente) utilizzare i pacchetti dal mio database dei pacchetti utente in concomitanza con la sandbox creato da cabal-dev. (Forse sto stampando il mio script in stile cabal-dev ghci?)

2. Un suggerimento su come migliorare il mio flusso di lavoro in modo che il problema scompaia.

So che potrei semplicemente installare il pacchetto a livello globale, ma sono riluttanti ad inquinare il mio database dei pacchetti globale in questo modo (e cabal-dev scoraggia esplicitamente).

Mille grazie per tutti i consigli.

Answer 1

Penso che la soluzione più semplice sia solo installare le cose che ti servono nella sandbox. Ad esempio, se avete bisogno di Aeson per lo script interattivo:

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

Poi :set -package aeson dovrebbe funzionare in ghci.

Se questo è inadeguata, si hanno un sacco di dipendenze che si desidera utilizzare dal proprio database dei pacchetti utente e non c'è bisogno ghci ad essere invocate con le altre bandiere che i set di file cabala per invocare ghc, allora si può invoca il numero ghci non sabbioso con accesso ai pacchetti dalla sandbox e ai pacchetti utente e globale. Per esempio (per GHC 7.0.3):

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

(noti sia i due punti alla fine del GHC_PACKAGE_PATH e lo spazio tra questo e ghci.)