5

I installed diagrams, and it seems to be there, but GHCi doesn’t find it. I tried adding the local sandbox to the command line (-package-db), but still no luck. Any suggestions?

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

I find it in:

  C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d
        (diagrams-1.2, diagrams-contrib, -core, -lib, -svg)

But running: “cabal repl” or using the GHC(i) flag “-package-db=…” fail to find it:

C:\Users\guthrie>cabal repl
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m + Diagrams.Prelude

<no location info>:
    Could not find module `Diagrams.Prelude'
   It is not a module in the current program, or in any known package.
Prelude>

To clarify; ignoring the cabal invocations, using GHC/i directly, and the program diagramsDemo.hs:

--  http://projects.haskell.org/diagrams/doc/quickstart.html
--
import Diagrams.Prelude
import Diagrams.Backend.SVG.CmdLine

main = mainWith (circle 1 :: Diagram B R2)

Gives:

C:\Users\guthrie\Desktop\xFer\Graphics>ghc --make diagramsDemo.hs

diagramsDemo.hs:7:8:
    Could not find module `Diagrams.Backend.SVG.CmdLine'
    Use -v to see a list of the files searched for.

C:\Users\guthrie\Desktop\xFer\Graphics>ghc --make diagramsDemo.hs -package-db=C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d

diagramsDemo.hs:7:8:
    Could not find module `Diagrams.Backend.SVG.CmdLine'
    Use -v to see a list of the files searched for.
guthrie
  • 4,529
  • 4
  • 26
  • 31
  • 1
    If the `diagrams` package isn't specified as a dependency in your `.cabal` file it won't be available from `cabal repl` (a mis-feature, IMO). You can get around this with `ghci -no-user-package-db -package-db=./.cabal-sandbox/i386-windows-ghc-7.6.3-packages.conf.d`, which I've made an alias for in my install of cygwin bash. – bheklilr Feb 20 '15 at 15:00
  • Thanks - but ignoring cabal-repl approach, it seems like ghci -package-db=... should be enough for ghc/i to find it. I have the same application on an adjacent machine, and it works fine, finds any/all installed packages. So teh Question is why the -db argument should not be enough to find it, when cabal install does. – guthrie Feb 20 '15 at 19:51
  • When you use `cabal repl`, it loads the dependencies you've specified for your project. You can definitely install other packages into a sandbox, but that doesn't mean they're available to import. The `-package-db` flag adds an additional package database to scan when simply ghci is looking for packages, but I prefer the `-no-user-package-db` flag as well since it prevents conflicts with my system install of cabal. – bheklilr Feb 20 '15 at 19:54

1 Answers1

6

As bheklilr said, if ghci is started with cabal repl, it will only find packages specified as a dependency in the .cabal file.

However you can start it with cabal exec ghci, then it will find all packages installed in the sandbox.

The same is true for invoking ghc (cabal build vs. cabal exec ghc), but note that if you want to pass flags you have to use --, like in cabal exec ghc -- -O2 Main.hs. Alternatively you can use cabal exec bash and launch ghci or ghc in the new shell.

cabal exec was added with Cabal 1.20.

ipsec
  • 680
  • 4
  • 11
  • Hmm, not sure if this really answers the issue - I am running ghc/ghci directly, not via cabal. and to have it find packages in the sandbox I added the -package-db=./.cabal-sandbox... option. I have a single pgm.hs file, and no .cabal file, and should not need one. This same procedure works on the adjacent machine, so the procedure seems correct - but the result fails on this machine. – guthrie Feb 21 '15 at 04:54
  • Yes, it should be possible to give some flags to `ghci` to find the packages in the sandbox. I don't know, why it does not work in this case. But I find it easier to use `cabal exec` if you are using a Cabal sandbox. This is also more robust in regard to future changes to the sandbox structure. – ipsec Feb 21 '15 at 09:11
  • Thanks - I did not know about "_cabal exec ghc_", will look more at that, but it looks to me like there is something messed up with my cabal databases in general. I find that 80% of problems and time wastes and failures with Haskell are cabal related, and I have to just periodically rebuild and reinstall all libraries, and even then lots of things fail (xxHaskell, gtk+, ...). – guthrie Feb 21 '15 at 14:05