Well in some cases, it might not be easy to break up the libraries.  If there is sufficient mutual dependency, doing so won't even help the situation.  However, I already looked at the code to some large libraries, such as xmonad-contrib, and gtk2hs and am certain that no code modifications are needed for these libraries to be broken into more manageable "books".  Often times, like is the case with xmonad-contrib and gtk2hs you have a core library that is required by a large "cluster" of smaller modules.  But those smaller modules are not mutually required between themselves.  From a technical standpoint, it might be nice to have a way to declare such a grouping within hackage or cabal, but no technical change is necessary for the philosophical change I am recommending. One thing I certainly don't want to do, is to "strong arm" library maintainers into breaking up their mega-packages into more easily maintained parts ;)  This has to be a decision made by the individual package maintainers, rather than some "policy" that comes down from "those who know best" upon the shoulders of the hard working members of our community... Timothy ---------- Původní zpráva ---------- Od: Alfredo Di Napoli Datum: 18. 11. 2012 Předmět: Re: [Haskell-cafe] A small step towards solving cabal hell. " 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 :) Cheers, Alfredo On 18 November 2012 13:33, 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/XMo...) has no mutual dependency on XMonad.Layout.Circle (http://hackage.haskell.org/packages/archive/xmonad-contrib/0.10/doc/html/XMo...) . 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@haskell.org(mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe) " "

I understand your concern.  Of course with cabals current implementation this proposal requires a lot of fluff.  I thought about implementing a cabal syntax directly into Haskell pragmas, getting rid of the cabal file format entirely.  I think that would be a pie in the sky optimum.  However, I don't think that such fluff is the death of my proposal.  Wikipedia seems unmaintainable after all, with so many hundreds of thousands of articles.  Yet it is maintained by the sheer force of millions of contributors.  Lowering the boundary for new contributors to step up and help maintain these new micro-packages, by shrinking and simplifying the packages, will solve the very problem it creates. Timothy ---------- Původní zpráva ---------- Od: Brandon Allbery Datum: 18. 11. 2012 Předmět: Re: [Haskell-cafe] A small step towards solving cabal hell. " On Sun, Nov 18, 2012 at 10:15 AM, wrote: " Well in some cases, it might not be easy to break up the libraries.  If there is sufficient mutual dependency, doing so won't even help the situation.  However, I already looked at the code to some large libraries, such as xmonad-contrib, and gtk2hs and am certain that no code modifications are needed for these libraries to be broken into more manageable "books".  Often times, like is the case with " There's another consideration, which is are you optimizing hackage by pessimizing development?  You could break xmonad-contrib into (usually) one package per module if you really wanted to --- but now the developers need to track a couple hundred packages and possibly as many darcs or git or whatever repos. You've just nibbled that project to death by making it too difficult for developers to bother with. (cabal doesn't really let you have multiple packages per source tree currently; this would help some, but I suspect that would just expose more shortcomings in hackage with that kind of package setup.) -- brandon s allbery kf8nh                               sine nomine associates allbery.b@gmail.com(mailto:allbery.b@gmail.com)                                  ballbery@sinenomine.net(mailto:ballbery@sinenomine.net) unix/linux, openafs, kerberos, infrastructure          http://sinenomine.net (http://sinenomine.net) "

You are correct this won't help(and may even hurt) in places where there is true mutual inter-dependency between parts of libraries.  But I gave examples where I was sure this was not the case. Timothy ---------- Původní zpráva ---------- Od: Brandon Allbery Datum: 18. 11. 2012 Předmět: Re: [Haskell-cafe] A small step towards solving cabal hell. " On Sun, Nov 18, 2012 at 11:04 AM, Brandon Allbery wrote: " There's another consideration, which is are you optimizing hackage by pessimizing development?  You could break xmonad-contrib into (usually) one package per module if you really wanted to --- but now the developers need to track a couple hundred packages and possibly as many darcs or git or whatever repos. You've just nibbled that project to death by making it too difficult for developers to bother with. " It also occurs to me that you might have also made the original problem much worse instead of better:  now we have a hundred or so micro-packages that can get into diamond or worse dependency conflicts, where there was only one possible source of conflict. -- brandon s allbery kf8nh                               sine nomine associates allbery.b@gmail.com(mailto:allbery.b@gmail.com)                                  ballbery@sinenomine.net(mailto:ballbery@sinenomine.net) unix/linux, openafs, kerberos, infrastructure          http://sinenomine.net (http://sinenomine.net) "