GHCI Cannot Find Nix-Built Libraries

#1

Given the following snippet from my ~/.ghci:

import qualified IPPrint
import qualified Language.Haskell.HsColour as HsColour
import qualified Language.Haskell.HsColour.Colourise as HsColour
import qualified Language.Haskell.HsColour.Output as HsColour

I expect it to find the libraries that were built and installed under my user’s profile. I can’t seem to figure out how to get the libraries, installed with:

nix-env -f "<nixpkgs>" -iA myHaskellEnv

where myHaskellEnv is a function that is defined in ~/.config/nixpkgs/config.nix, per the developer docs in the manual:

    myHaskellEnv = self.haskell.packages.ghc844.ghcWithHoogle
        (haskellPackages: with haskellPackages; [
            # libraries
            arrows
            async
            cgi
            criterion
            zlib
            pure-zlib
            zlib-bindings

            # tools
            haskintex
            hscolour
            ipprint

            # haskellPackages.
            happy
        ]);

Anyway, I’m trying really hard to make this all work happy, but am stymied at every turn, really frustrating. What am I not loading/doing to get libraries that are built to be recognized?

0 Likes

#2

So, it turns out that Cabal installs an environment file when you run it. In my case, that file was called, “.ghc.environment.x86_64-linux-8.4.4”. Stack also does something similar, ignoring environment settings and loading its own config. That file was called, “/run/user/1000/haskell-stack-ghci/a8ea6cf3/ghci-script”. If you start ghci with just ‘ghci’, it loads your default environment file, in my case, “/home/dave/.ghc/x86_64-linux-8.4.4/environments/default”. This turns out to be the environment file I wanted to load, the one that was set up for NixOS by the function above. So, now my question is, do tools like Stack and Cabal require further configuration to make them work properly with NixOS?

0 Likes

#3

After much fiddling, I’ve come to understand that ‘stack ghci’ intentionally ignores user package databases. It goes so far as to ignore them, then ignore my attempts to pass arguments to ghci that would load the user package databases anyhow. So I give up. Apparently ‘stack ghci’ is just broken on NixOS. You’ll be happier if you follow the developer guide for NixOS and just run ‘ghci’ directly. I guess I’ll see what happens when I start making non-trivial apps…

0 Likes

#4

Hi,

You can put write-ghc-environment-files: never in ~/.cabal/config if the .ghc.environment file is causing problems.

I also use myHaskellEnv with ghci. This provides wrappers around GHC setting up a global package DB containing your chosen packages. The only difference with mine is that I use haskellPackages rather than haskell.packages.ghc844, so that I get a recent GHC with packages from the binary cache.

If you are using cabal new-build on your project, the Cabal solver will not necessarily choose packages from the global package DB. It may want to download and build packages according to its own plan.

I only use stack ghci within Stack projects. Otherwise, plain ghci is fine. On NixOS, you always need Stack/Nix integration enabled. Stack will also manage its own package builds, and doesn’t care about the myHaskellEnv you have installed.

Cheers,

Rodney

1 Like