haskell: share modules across sandbox(es)?

Question

I did an install of Diagrams, and all seemed fine.

>cabal install diagrams
Resolving dependencies...
All the requested packages are already installed: diagrams-1.2
Use --reinstall if you want to reinstall anyway.

But if I try to use it: import Diagrams.Prelude

 Could not find module `Diagrams.Prelude'
  Use -v to see a list of the files searched for.

And:

>ghc-pkg list diagrams
WARNING: there are broken packages.
Run 'ghc-pkg check' for more details.
e:/Plang/Haskell Platform\lib\package.conf.d:
    (no packages)
C:\Users\guthrie\AppData\Roaming\ghc\i386-mingw32-7.8.3\package.conf.d:
    (no packages)

(The broken packages are all old versions of things that have a good newer version installed.)

It seems to be installed in .cabal-sandbox, but that is not reported by ghc-pkg (?):

C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.8.3-packages.conf.d\Diagrams...

I understand that instead of GHCi I could use “cabal repl” which would add additional package library references to this to the path, but I want to use these installed libraries from other Haskell IDEs (Heat, Leksah).

I am not sure if this sandbox is a remnant for a previous cabal-install that would not work otherwise, or if the new cabal version (1.22) uses them automatically, or…

I found that using “cabal exec ghc” might solve this, but I tried it, and although putting in the explicit path myself worked, I didn't find the right usage for this:

-- Good:
ghc --make Program.hs -package-db=c:\users\name\.cabal-sandbox\i386-windows-ghc-7.8.3-packages.conf.d\
-- Fails:
cabal ghc --make Program.hs

Also current IDEs don’t have this option. Do I have to then add a command line option pointing to this directory ( -package-db= ) to all other tools that use GHC? and is this the right approach?

Is this a sandbox in a project directory (ie, same folder as a .cabal file)? If so, then an IDE which integrates with cabal should use it automatically (since cabal does so) when building the project. If you are using the sandbox just to keep your global/user package db's clean, then just alias ghc to ghc -package-db=... - this is what I do. This may not work, for example if your IDE calls ghc with an absolute path - so it would be helpful to know exactly what command your particular IDE calls. — user2407038
You can use cabal repl to start GHCi with the packages from the sandbox available. — Cactus
No, not a local sandbox, one global one in home directory (c:/users/name/.cabal-sandbox...). Windows doesn't have the concept of alias'es - I would have to fiddle with the Haskell-platform installation, and that might break things. I thin all IDEs use direct path resolution of GHC.exe by default. Somehow the automatic use of sandboxes and previous uses of GHC do not seem perfectly integrated (yet?). — guthrie

bergey bergey · Accepted Answer · 2015-02-11T15:23:30

In general, IDEs and other tools which call cabal / GHC need to be aware of sandboxes, and behave a bit differently depending on whether or not there is a sandbox. I can't speak to Leksah, but for emacs, knowing the CLI way makes setting up the IDE easier.

The sandbox-aware equivalent of ghci is cabal repl.

The sandbox-aware equivalent of ghc-pkg is cabal sandbox hc-pkg.

It may be worth cabalizing the Diagram that you want to build. I know this seems overkill for a single Haskell file that only depends on diagrams-lib. I find it takes less time to create a .cabal file (or add an executable section to a common my-diagrams.cabal) than to figure out how to make all the tools (emacs haskell-mode, ghc-mod, hslint, GHC) pick up packages from a sandbox while building a non-cabalized file.

haskell: share modules across sandbox(es)?

1 Answers