On Sat, May 10, 2014 at 4:30 AM, Alexander Berntsen
I just wanted to say that this whole thread is close to scaring me off *ever* putting a library on Hackage. I have worked in free software for quite some time, and let me assure you that it's not common practice elsewhere to hijack software if the maintainer does not respond for four days.
I strongly agree, which is why I almost never put anything on hackage, it's a pretty fundamentally broken model. If your configuration manager can be broken by an external dependency in a way that cannot be locally resolved, then your configuration manager is not doing its job. Depending on hackage packages is the number one reason for haskell code breakage and code-rot. I pull out code I wrote myself just 3 years ago and find it can't build on a sligthly newer version of the same compiler, yet C code, written to a 20 year old version of the language on a different OS with a different compiler still adapts and works out of the box. We have somehow made a more messed up dependency situation than C has. Putting something on hackage means getting on the upgrade treadmill, I had utterly portable pure haskell 98 libraries, people kept trying to "maintain" them out from under me to being non-portable, meaning I have to actively maintain it because it is no longer written to a standard or give up on the hackage version which leads to confusion. I want to write code, not twiddle dependencies for versions of ghc I don't even use. It is telling that the best way to port cabal/ghc libraries to jhc is just delete the cabal file and compile it anyway, despite the cabal file claiming it depends on all sort of specific versions of things. _almost every broken build is due to cabal having incorrect info and the package works perfectly as is_, as in, cabal is actively making code _less_ portable. And, I can't rightly blame the author, they had to put some arbitrary max version, and hardcode some package names that are ghc specific, and they probably never even heard of the compiler i'm trying to use. But none of these should be issues for a real configuration manager it is exactly its job to _make things like that work_. Sigh. I have ranted this rant before. It is a real turn off to see how much cabal build issues eat away at the general Haskell language list traffic. It depresses me and I go away for a while. When you make a system requiring work proportional to the square of code on hackage rather than linearly then eventually all Haskell hacker brain cycles will be subsumed by hackage library maintenance. John