NixOS/nixpkgs — pull request #5060 by jraygauthier (2014-11-20 05:12:04+00:00)
Title: First attempt at fixing haskell packages collision issues with native ghc packages.

Merely a proof of concept at this point. Aim is to find a clean fix with
the help of the community.

I had this issue with making gitit work with plugins enabled. However, whenever I
attempted to use `ghcWithPackages` I had a collision issue. Following advices from
blogs I started using `ghcWithPackageOld` which simply skipped collision warnings.

This allowed me to build my haskell environement. However, my plugins were not
able to find `Network.Gitit`. I had the same issue within ghci and the package `gitit`
was properly listed when running the command `ghc-pkg list`.

I dug a bit deeper just to find that when explicitly loading the package using
`ghci -package gitit` I had a more helpful error message which lead me to find that
the underlying problem was with the `xhtml-3000.2.1` package which could
not be found by `gitit`, `recaptcha` and `happstack-server` packages. Then I
decided to run `ghc-pkg list` again just to find out that the `xhtml-3000.2.1`
was listed twice. So my first logical conclusion was that there must be an
ambiguity problem. I just had a look at my env's `lib/ghc-7.8.3` directory. In
there I found there was a single folder for this package and a single entry
under `package.conf.d`. I dug yet a bit deeper through symbolic links just to
find out that this package was one of the package shipped with ghc 7.8.3
explaining perfectly why it was registered twice with ghc-pkg. I did confirm
that when I built an empty hsenv.

I attempted first to remove this `xhtml` buildDepedency from all of my 3
packages and it worked like a charm. No longer any need for the
`ghcWithPackageOld` hack, my 3 offending package + xhtml were
now explicitly loadable from ghci.

This was however only a hack. I needed a real solution. This is when I
had this idea of moving the ghc native package filtering pass to the *cabal*
expression. Note that it could as well have been implemented in the
*ghcWithPackages* expression.

Now, if the is an accepted way of fixing the problem, we will need a more
permanent ways of having a ghc version list the packages that come built-in
with its build. I believe this belongs to the particular ghc version's nix expression.
If so, I will need some help as to how best to express this in nix.