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.
Indeed. I've always thought of the Haskell Platform as doing the "stable set" part, though there must be plenty of space between HP at one end and Hackage at the other, and that's what you are exploring I think.
Regardless, being able to install multiple instantiations of the same package/version is desirable for the "stable set" story, so that more than one stable set is possible; and so that trying to use a package outside the stable set doesn't mess up your stable-set installation.
The question is: who will do the work?
Simon
From: michael.snoyman@gmail.com [mailto:michael.snoyman@gmail.com] On Behalf Of Michael Snoyman
Sent: 22 November 2012 10:40
To: Simon Peyton-Jones
Cc: Haskell Libraries (libraries@haskell.org); cabal-devel@haskell.org
Subject: Re: Cabal and GHC
On Thu, Nov 22, 2012 at 10:32 AM, Simon Peyton-Jones mailto:simonpj@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
But I'd be unlikely to return there so I'm posting this to the libraries and cabal-devel lists.
I'm not deep in Cabal lore, but it seems to me that there is a fairly easy way to do a Lot Better than we are now. Let's go back to "Identifying the Problem". Michael doesn't say, but I'm guessing that Fay depends on yesod-platform. Very well, so Cabal sees
I'm installing Fay,
which depends on yesod-platform, which dpends on data-default
and depends directly on data-default
If the package database was empty, Cabal would try to figure out a version of data-default that is acceptable to both yesod-platform and to Fay. And that's what we want!
Suppose that Cabal figures out that yesod-platform-2.7 and data-default-0,4 would work. Then, in an empty package database, it could just go ahead and install those. But in your example, the database isn't empty; we have already isntalled yesod-platform-2.7, dependin gon data-default-0.5. And (here's the rub) you can only have yesod-platform-2.7 installed once.
One solution might be
1. *un* install yesod-platform-2.7 (depending on data-default-0.5) and
2. *re* install it (depending on data-default-0.4).
But that would break any programs that use both yesod-platform-2.7 and data-default-0.5.
The solution is obvious: we should make it possible to instally yesod-platform-2.7 twice,
once version depending on data-default-0.4
once version depending on data-default-0.5.
Now, if Cabal can figure out a plan based on an empty database, it can deliver on that plan even in a non-empty database, without messing up any existing installations.
Of course, if Fay depends exclusively on data-default-0.4, and yesod-platform depends exclusively on data-default-0.5, then they genuinely are incompatible, and Cabal can and should say so. That's not Cabal Hell. That's just saying that the package authors have *specified* that they are incompatible.
Summary. I may be way off beam here, but I think we can easily make things way better than they are. By "easily" I mean with just design and implementation work. That's not free, and no one has any time.... but it's well within reach. I'd even been wondering about trying to crowd-fund this development so that Well Typed can do it. But let's first see if it'd solve the problem.
There must be a wiki page somewhere that articulates the challenge, points to blog posts about it, and discusses solutions.
Simon
_______________________________________________
Libraries mailing list
Libraries@haskell.orgmailto:Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Hi Simon,
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.
MIchael
