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

[Miguel Negrão]

Hi Peter,

Peter Simons <simons <at> cryp.to> writes:
>  > 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.

Isn't the issue in https://github.com/NixOS/nix/issues/396 due to binaries
disappearing from hydra ? When that happens the only way I know how to
proceed is to build locally, which then gets me into the ghc id problem.
That was exactly what caused me to change nixpkgs commit and restart the
whole process of finding a stable nixpkgs commit for the packages I use. The
(temporary) solution to that bzip error is to remove mention of
hydra.crypt.to, correct ? 
 
>  > 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.

Ok, then the package updating is more controlled then I what I had
understood, sorry for suggesting otherwise. Also, the work of maintaining
the package set consistent is very much appreciated, not to mention again
how wonderful the new haskell-ng infrastructure is ! :)

>  > 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.

Ok, I understand. Once I have more time (finishing phD at the moment...ufff)
I will try to contribute fixes when I come across such problems (if it's
within my reach).

Again, thanks for all the work on the haskell infrastructure in nix !

thanks,
Miguel