[Nix-dev] haskell dev environment, ghc non-determinism and binary cache interaction

[Peter Simons]

Hi Miguel,

 > Ok, because of this I have decided to not use binary cache in case I
 > have to build packages locally later.

that's an unusual strategy, IMHO. It's fine to use a binary cache, you
should just avoid using more than one.


 > It seems to me that the haskell packages are now essentially not
 > curated since they come from hackage, and patches or changes of
 > version are done manually only after a while. Doesn't this mean that
 > we will never have a consistent set of haskell packages in master?

Our package set is as consistent or inconsistent as we -- the
contributors of Nixpkgs -- make it. We don't blindly take whatever is
the latest version on Hackage and commit that to "master". There are
multiple levels of control over what the package set looks like. [1]
determines which packages are available in the first place, and the
"configuration-*.nix" modules customize those versions for different
compilers. Those files change in a separate branch where hydra.cryp.to
build all packages before we manually decide to merge the changes into
the mainline. In my experience, our package set is in better shape than
ever before, so I'd hesitate to say it's not curated.


 > When diagrams was updated to 1.3 recently, IHaskell was broken
 > because it depends on 1.2. Maybe by the time the IHaskell maintainer
 > fixes this some other package will update and will break IHaskell
 > again. Wouldn't it make sense to try to have a consistent set of
 > haskell packages like stackage ?

In my experience, it is almost impossible to have a totally consistent
package set. When a library A releases a new version with breaking
changes, then some dependencies B will update to the new version and
some dependencies C won't. If you update A, then you break C. If you
don't update A, then you break B.

Now, sometimes this mess can be mitigated by keeping two (or more)
versions of A so that you can build B with the new version and C with
the old one -- but that setup fails once you encounter a package D that
depends on both B and C at the same time.

Generally speaking, there is no way we can keep *all* Haskell packages
building at the same time. The best we can do with our resources, IMHO,
is to make smart trade-offs to keep those building that we perceive as
particularly important.


 > Perhaps mirroring the versions in stackage?

Yes, we could provide a "haskell.packages.stackage" package set that
follows Stackage. I've always wanted to implement that in "hackage2nix".
It's not particularly hard, I just never had the time to get it done.


 > I would like to learn a workflow which is easier then what I'm
 > currently doing...

>From the sound of it, the best thing you can do is learn how to fix
Haskell build errors in Nixpkgs so that you can remedy those issues when
you encounter them. That would be beneficial for you personally, and
your changes also help everyone else have a nicer experience. The
article [2] should help getting you started, if you'd like to.

I hope this helps,
Peter



[1] https://github.com/NixOS/cabal2nix/blob/master/src/hackage2nix.hs#L252-329
[2] http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015608.html