Re: [Haskell-cafe] Cabal install fails due to recent HUnit

On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan wrote:

...

On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan wrote:

Not to flog a dead horse, but:

... Not to flog a dead horse, but:

All our builds broke again yesterday due to this bug. The package was iteratee-0.8.9.3, though given the vocal opposition of Bryan O'Sullivan, I won't advocate fixing it in place just now. ... I was going to argue to support versions of cabal (and GHC) for at least a year. That means that if you're on Ubuntu, which has releases every 6 months, you have 6 months to upgrade. However, that year has already expired for cabal 0.10, or is about to expire if you count the Ubuntu release it came with.

So what do others think? Does the haskell community want to support anything other than the bleeding edge? If so, for how long?

While we are all making glue, it really, really doesn't need to be like this! (Everybody is going to hate me for this and I am quite sure I am going to be ignored, but my conscience forbids me from staying quiet.) Every one of my Haskell Platform releases on justhub.org provides all the libraries and tools needed for that platform, which gets laid on top of the existing platforms (which can be removed when they are no longer needed). Each project can chooses its platform, and can pin whatever packages it needs to use without fear of being disrupted, while installing new GHC and platform releases for use with other projects. (Proper package erasure is supported too.) With trivial effort source trees can be moved around among different systems and rebuilt in the exact same configuration. The standard tools (ghc, ghci, ghc-pkg, cabal, etc.) can be used just as normal. All the developer needs to do is designate which platform (or bare ghc) to be used at the root of each work tree -- or leave it to use the platform-du-jour. I can only describe working with this kind of environment as peaceful (certainly not cabal hell). Trying to mutate and maintain coherent an ever-growing network of packages is not a scalable way of doing business. If on top of this the history gets patched up aren't things going to get even more confusing? I know that this way of doing things won't provide immediate relief (it's too radical relative to where everybody is) but I am trying to address Erik's question about what we should be aiming for. Shouldn't we be trying to find a sustainable, long-term, preferred method of delivering stable Haskell development environments? Why not a functional model? What is not to like? I will be at the CUFP if anybody would like to see a live demo or debate any of these points. Chris