atom feed15 messages in org.haskell.cabal-develRe: Cabal and GHC
FromSent OnAttachments
Simon Peyton-JonesNov 22, 2012 12:32 am 
Henning ThielemannNov 22, 2012 1:17 am 
Duncan CouttsNov 22, 2012 1:19 am 
Simon Peyton-JonesNov 22, 2012 1:19 am 
Edward Z. YangNov 22, 2012 1:27 am 
Simon Peyton-JonesNov 22, 2012 1:33 am 
Simon Peyton-JonesNov 22, 2012 2:44 am 
Vo Minh ThuNov 22, 2012 2:58 am 
Duncan CouttsNov 22, 2012 3:00 am 
Henning ThielemannNov 22, 2012 11:41 am 
Johan TibellNov 22, 2012 10:28 pm 
Simon MarlowNov 23, 2012 3:58 am 
Simon MarlowNov 23, 2012 4:06 am 
Jens PetersenNov 27, 2012 8:29 pm 
Simon Peyton-JonesNov 28, 2012 12:54 am 
Subject:Re: Cabal and GHC
From:Duncan Coutts (
Date:Nov 22, 2012 3:00:37 am

On 22 November 2012 10:39, Michael Snoyman <> wrote:

On Thu, Nov 22, 2012 at 10:32 AM, Simon Peyton-Jones <> wrote:

Michael Snoyman wrote a blog post about Solving Cabal Hall, which came across via the peerless Haskell Weekly News.

The solution is obvious: we should make it possible to instally yesod-platform-2.7 twice,

Having GHC support multiple copies of the same package/version would certainly be a step in the right direction. It still wouldn't completely address the goals I'm getting at in my blog post. What I'm really aiming for overall is to provide users with a stable, vetted set of packages that are known to work well together. But for those of us who will still be using plain Hackage, this improvement would be very helpful.

Right, and we need both. Your suggestion is very sensible. It's similar to the suggestion people have made before about having "testing" and "stable" sets of packages (these suggestions often come from people using debian terminology), and managing things like a distribution. In both cases the point is to provide something to end users where we've set up the available packages such that we know most things work together. (This is why debian users don't run into problems most of the time, because volunteers have done a huge amount of work behind the scenes to eliminate conflicting versions).

So yes we need that, and it will require a fair bit of work, and we need to distribute that amongst many people. I think eventually the best mechanism to do it will be to use hackage and use tagging, but we can certainly experiment now by using separate hackage instances.

But we also need to address the problems of developers in the thick of things, who must work with the latest and greatest unsable versions, before people have got round to smoothing out all the conflicting dependencies and patching packages so they can all use the same versions of common dependencies.

That's where the nix-style approach that we've been advocating for years comes in. That's what Philipp Schuster's GSoC this summer was all about. That's aiming to do exactly what Simon is talking about here. It's about allowing sets of packages to be installed simultaneously that have inconsistent sets of dependencies. There's a slight overlap with sandboxing, but the way I see it, the nix approach is the right underlying implementation mechanism and then sandboxing is more of a UI issue.