[Haskell-cafe] An Easy Solution to PVP Bounds and Cabal Hell

[Andras Slemmer]

10/10

"enforce immutability, but allow retroactive mutation". Word. Finally a
simple and coherent solution

On 1 April 2015 at 06:22, Gershom B <gershomb at gmail.com> wrote:

> Recently there has been some discussion about how we can fix the problem
> of “Cabal Hell”. Some people advocate restrictive upper bounds, to prevent
> packages from being broken by new updates. Some other people point out that
> too-restrictive bounds can lead to bad install plans, since some packages
> might want newer versions of some dependencies, and others older versions.
> Still other people say that we can _retroactively_ fix upper bounds (in
> either direction) by modifying cabal files using the new features in
> Hackage. Some people think this is a terrible idea because it looks like we
> are mutating things, and this confuses hashes. In turn, these people
> support either nix or a nix-like approach by which packages have hashes
> that encompass the full versions of all their transitive dependencies. With
> that in hand, we can cache builds and mix-and-match to build the precise
> environment we want for each package while reducing redundant computation.
> However, the cache of all the various binary combinations may still grow
> large! And none of this fully begins to address the dreaded “diamond
> dependency” problem.
>
> Here is a chart of some such solutions:
> http://www.well-typed.com/blog/aux/images/cabal-hell/cabal-hell-solutions.png
>
> One way to look at a particular build is in an n-dimensional state space
> (of the Hilbert sort) determined by all its dependencies, not least the
> compiler itself. The solver acts as a particle traversing this space. But
> this description is too simple. Our state of dependencies and constraints
> itself varies and grows over time. So another approach is to think of the
> dependencies as a transitive graph, where each node may vary along a time
> axis, and as they slide along the axis, this in turn affects their
> children. We now have not just one Hilbert space, but a collection of them
> related by branching trees as authors locally modify the dependencies of
> their packages.
>
> If we keep this simple model in mind, it is easy to see why everyone is
> always having these debates. Some people want to fix the graph, and others
> want to simplify it. Some people want an immutable store, and some people
> want to rebase. But we can’t “really” rebase in our current model. Bearing
> in mind our model of a space-time continuum of hackage dependences, the
> solution emerges — enforce immutability, but allow retroactive mutation.
>
> For instance, suppose Fred tries to install package Foo on Friday evening,
> but discovers that it depends on version 1.0 of Bar (released the previous
> Friday) that in turn depends on version 0.5 of Baz but Foo also depends on
> version 0.8 of Baz. So Fred branches Bar and changes the dependency, which
> in turn informs Betty, that there is also a 1.0 of Bar with different
> dependencies and we have forked our package timeline. On getting this
> message on Monday, Betty can merge by pushing with --force-rewrites and
> this goes back in the timeline and makes it so that Baz retroactively had
> the right dependencies and now Fred, as of the previous Friday, no longer
> has this problem. (That way he still has the weekend). Now the failed build
> is cut off temporarily into a cycle in the package timeline that is
> disconnected from the rewrite. We stash it with “hackage stash” until
> Monday at which time the dependency graph is 100 percent equalized and
> primed for new patches.
>
> At this point we unstash Foo as of Friday and it is replaced by the Foo
> from the new timeline. Friday Fred needs to remain stashed lest he run into
> himself. The longer he can be avoided by his Monday self the better. Future
> work could include bots which automate pruning of artifacts from redundant
> branches.
>
> If this description was too abrupt, here is a diagram with a fuller
> description of the workflow: http://bit.ly/15IIGac
>
> I know there are some new ideas to take in here, and there is a little
> technical work necessary to make it feasible, but in my opinion if you can
> understand the current cabal situation, and you can understand how git and
> darcs work, then you should be able to understand this too.
>
> Hopefully by this time next year, we’ll be able to say that our problems
> with cabal have been truly wiped from our collective memory.
>
> HTH, HAND.
> Gershom
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150401/ce898b2e/attachment-0001.html>