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

[Chris Dornan]

>On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan <bos at serpentine.com>
wrote:
>> On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan 
>> <bos at serpentine.com>
>> 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