[Haskell-cafe] Cabal hell

[Patrick Redmond]

Since learning Haskell I've had the pleasure of finding my way out of a
cabal hell or two. I've developed some knowledge to cope with it [1], but
mostly concluded that if I can avoid burdening my projects
with dependencies that have many of their own dependencies, then cabal hell
can be averted. This puts somewhat of a damper on the joy of haskell's
composability.

With the new release of GHC I've observed a flurry of discussion on haskell
mailing lists and from Linux distro maintainers about all the fixing and
patching required to keep the haskell ecosystem going.

Meanwhile I've learned other languages and used other tools that don't seem
to have this problem that haskell does. For example, in the elm-lang
community the package management tool enforces strict api-versioning, and
in the clojure ecosystem people talk about "repeatability" and achieve it
by using mostly exact-version requirements, even including the language
(the language version is a dependency of a project, rather than a
constraint of the environment).

I guess I'm wondering why we don't try something simpler to solve the
haskell cabal hell problem. How about using minimum version dependencies
only, not ranges, since we can't accurately guess about the future
compatibility of our projects. How about automatic api-versioning of our
projects to give the version numbers some rigid semantics with regard to
package compatibility?

[1] http://f06code.com/post/90205977959/cabal-usage-notes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150409/ae878b3b/attachment.html>