[Haskell-cafe] A small step towards solving cabal hell.

Alfredo Di Napoli alfredo.dinapoli at gmail.com
Sun Nov 18 15:02:30 CET 2012

Hi Tim,
it seems a good idea, although I hardly believe such isolation is
achievable in practice. Just a feeling, though :)
However, I really hope we, as a community, will be able to finally fix the
Cabal Hell. It's a topic with a lot of hype lately,
but few "practical, hands dirty" approaches :)


On 18 November 2012 13:33, <timothyhobbs at seznam.cz> wrote:

> I've read a lot of negative regarding the problems with cabal and hackage.
> I've written quite a few of them myself.
> I want to propose a simple change in philosophy of packages.
> Haskell has inherited a philosophy from the imperative world,
> that there are two types of packages:
> Libraries and applications.
> Libraries are big collections of modules.
> Applications are big collections of modules.
> There is a difference from the perspective of the build system.
> Applications are big collections of modules that belong together and
> mutually rely upon each other for the application to work. Such that if one
> module is missing, the application cannot build and thus cannot do useful
> tasks.  If an application doesn't build, then the maintainer has to go and
> fix that problem.  This isn't perfect, I do not solve this problem in this
> email.
> Libraries don't always have this property.
> For example, XMonad.Layout.Column<http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Column.html>has no mutual dependency on
> XMonad.Layout.Circle<http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMonad-Layout-Circle.html>
> .
> This is a feature of libraries that can and should be taken advantage of
> wherever possible :)
> We can and should,
> break up libraries into "books".
> I hold this opinion,
> because libraries are hard to maintain.
> If xmonad-contrib refuses to build,
> I open up it's source code,
> and see some hundred modules.
> I cannot,
> as a non-xmonad developer,
> imagine myself fixing such a large library.
> But if it was just one small module from that library I wanted,
> and it refused to build,
> and I opened it up,
> and there were just 3 files there.
> I wouldn't feel so overwhelmed.
> I would fix the problem myself.
> What I'm trying to say,
> is that "books"
> (small packages containing 3 modules or less)
> are so easy to maintain,
> that they really need no maintainer at all.
> Any idiot can fix one.
> But libraries,
> with their hundreds of modules,
> and seemingly endless dependencies,
> Can be much harder to maintain,
> and require a knowledgeable maintainer.
> So lets stop publishing libraries,
> and maintaining libraries,
> and listening to people crying when libraries don't build,
> and lets start writing books,
> and publishing really small packages,
> that are so simple anyone can fix them when they break
> even when they have no in depth knowledge of the package.
> Lets make a new guideline for "libraries"
> that if it is possible to split a library into two or more,
> non-mutually dependent parts,
> than we *should* split them such.
> Timothy
> PS,
> I noticed that yesod is already a collection of "books",
> but it appears to me, that these packages are STILL mutually dependent :(
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121118/ef2cd1de/attachment.htm>

More information about the Haskell-Cafe mailing list