
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

On Thu, 22 Nov 2012, Simon Peyton-Jones wrote:
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.
Does ghc-pkg allow to have two different versions of yesod-platform-2.7 being installed?

On 22 November 2012 09:17, Henning Thielemann
On Thu, 22 Nov 2012, Simon Peyton-Jones wrote:
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.
Does ghc-pkg allow to have two different versions of yesod-platform-2.7 being installed?
No, not right now. But the point is, if it did... Duncan

| Does ghc-pkg allow to have two different versions of yesod-platform-2.7 | being installed? Not at the moment. But it should! S | -----Original Message----- | From: Henning Thielemann [mailto:lemming@henning-thielemann.de] | Sent: 22 November 2012 09:18 | To: Simon Peyton-Jones | Cc: Haskell Libraries (libraries@haskell.org); cabal-devel@haskell.org; | Michael Snoyman (michael@fpcomplete.com) | Subject: Re: Cabal and GHC | | | On Thu, 22 Nov 2012, Simon Peyton-Jones wrote: | | > 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. |

Excerpts from Simon Peyton-Jones's message of Thu Nov 22 00:32:27 -0800 2012:
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.
This is an interesting invariant, weaker than the more obvious one: "Cabal should do the same plan no matter what the state of the database is" which is in tension with "don't install more than you have to." Edward

| > 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. | | This is an interesting invariant, weaker than the more obvious one: | "Cabal should do the same plan no matter what the state of the database | is" which is in tension with "don't install more than you have to." Well I didn't say it should *ignore* the database. The current database might influence its plan. For example if, after installing both yesod-platform and Fay, Cabal is asked to install a package P which depends on yesod-platform data-default 0.4-0.8, then Cabal could pick the already-installed version of yesod-platform depending on data-default 0.5, rather than installing yet another version depending on data-default-0.8. So the invariant I suggest is * If it'd work in an empty database, it should work in any non-empty one * Installing X should never break the existing installation of Y Simon
participants (4)
-
Duncan Coutts
-
Edward Z. Yang
-
Henning Thielemann
-
Simon Peyton-Jones