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 _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
