Cabal and GHC

[Duncan Coutts]

On 22 November 2012 10:39, Michael Snoyman <michael at snoyman.com> wrote:
>
> On Thu, Nov 22, 2012 at 10:32 AM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:
>>
>> Michael Snoyman wrote a blog post about Solving Cabal Hall, which came
>> across via the peerless Haskell Weekly News.
>> http://www.yesodweb.com/blog/2012/11/solving-cabal-hell

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

Duncan