Hacker News Reader

Yeah, cabal isn't quite there yet. People are aware of the issues and are working on them, but it's a slow road.

As a workaround, my modus operandi right now is to use virthualenv and build everything in there. I understand cabal-dev provides similar functionality, but I haven't used it. I've never had dependency conflicts when I build something from hackage in a virthualenv, so if you're still interested in trying it you might want to give that a shot.

Thanks! I didn't know about virthualenv. Cabal's lack of uninstall, plus those dependency problems, will make this a must for me when I experiment with Haskell.

If you just want to install the binaries, look for a binary package (Ubuntu's got one, so Fedora might have one too).

If you really want to install from source, try cabal-dev (worked for me, see my other comment) or virtualhenv.

You don't want to take any development libs from your distro. At most, take the compiler (if the version is good) and install the rest in your home dir. The libs that come with your distro are intended to support applications that come from the distro. Usually that means that the libs are quite old and developing or running new projects with those will fail.

For development work and reliable deployment, use the libs from your language's package manager (cabal, pip, easy-install, npm, cpan, rvm, bundler). For applications from your distro, use the packages in your distro.

Hmm, I'm not sure if you're disagreeing with anything I said... when I wrote binary packages, I meant gitit's. If you just want to use it, you don't need need any dev libs.

All distros are way behind on shipping Haskell and it's not very easy to build from source because of the bootstrapping problem. This is being worked on.

However, your statement about Ruby, Python, Perl and Node is BS. Especially Ruby is very hairy to get up and running unless you are happy with old versions from your distro. Setting up the Haskell platform is not a lot more difficult than tinkering with rvm and bundler and whatnot to get Ruby up and running. Python is a little better because most useful libs are included in the "batteries" that ship with the interpreter. But try to use a bunch of libs and you enter virtualenv hell.

And whenever a new major change comes out, a new world of hurt begins. Ruby 1.9, Python 3 and Perl 6 transitions have been really painful.

If these languages work better, it's only because your distro package maintainers spend more time working on it.

I'm fairly certain I was able to just 'aptitude install gitit' on debian stable, edit the config file and 'gitit -f gitit.conf' to be up and running.

Exactly. You should be able to do that. The libs that come from apt should be compatible with the applications that come from apt.

But you cannot grab some software sources from dev repos (e.g. git clone gitit) and then install the required libs from apt and expect it to work. It may work if all the dependency libraries are very mature and stable, but that's not usually the case.

All distros are also volunteer projects who are happy to accept packaging submissions from the community.

And I don't understand the "new major change" bit. I have base 4.3, apparently gitit won't run without 4.4. Are you seriously saying that's a version bump comparable to Python 3?

> All distros are also volunteer projects who are happy to accept packaging submissions from the community.

You, sir, greatly underestimate the efforts that distro package maintainers do.

> I have base 4.3, apparently gitit won't run without 4.4. Are you seriously saying that's a version bump comparable to Python 3?

No, that version bump is not as significant. But it may introduce incompatibilities nevertheless. These may or may not be applicable to gitit, but that is determined what gitit defines in their cabal build files.

Sometimes these minor changes can be worked around by modifying the cabal build files of the project you're building with relaxed version numbers, but it works only in the simplest of cases.

> You, sir, greatly underestimate the efforts that distro package maintainers do.

Given that I've actually been paid to do exactly that professionally, I assure you that I'm not. But to be blunt: if you're not willing to ship usable software, don't claim to be shipping a "Platform". If you want to play in your unstable garden forever, that's great. The rest of us just won't care.

This isn't cabal's fault. (Though the error message could certainly be clearer.) That message essentially means that your GHC is too old to build gitit, since the base package version is tied directly to the version of GHC.

I'm not saying this is a software bug, I'm saying it's a broken platform.

The package tells me it's version 7.0.4, released 15 June 2011. It's the version currently packaged by Fedora, and it's barely a year old. Yet it's already incompatible with new software?

You have just discovered the truth behind "Haskell is a standardized language. Anybody can write a compiler for it."

Exactly. The sad thing is that I tried to install it precisely because it's the sort of thing (interesting new software[1] I want to try!) that I almost never see from the Haskell community. Yet I can't (well, won't), because the only way to use it is to build and install the bleeding edge version of the whole stinking platform from source. Yuck.

[1] Software that integrates well with the existing OS environment, to boot (again, something often sorely lacking inside the Haskell gardens). I mean, it uses git and runs as a self-contained web service. It looks nifty.

Is it a better option to go stale and stabilize bad APIs before they mature?

Haskell is one of the fastest moving languages out there. Don't be surprised if your distro can't keep up.

Hmm, I don't think that's the case. Could you elaborate on why you think ghc's version is the culprit?

I've just built gitit using cabal-dev and ghc 7.0.3. So more likely it's just an old case of "cabal hell".

This is puzzling. Did something instruct you that you needed to re-install cabal-install? You would already have had a copy as part of the Haskell Platform. You also already had `old-time` since it's part of the Haskell Platform too. Maybe something was overwritten in the `yum -y cabal-install`? There are several possibilities. It bugs me in any case that yum wasn't warning you that it had already installed `cabal-install`.

It is probably something very simple but would be much easier to figure out in real time, e.g. on the #haskell irc channel which generally handles such difficulties promptly. E.g. does a look at `ghc-pkg list` and `ghc-pkg check` suggest that something was broken?

(By the way, the comparison with Ruby and Python and Perl and Node is not that great; cabal is as much, or more, like `make` than `gem`, managing compilation, linking etc.; one uses it all the time locally where distribution is not in question; it looks like that is the aspect that you are bumping into.)

I didn't have "the Haskell Platform". So I got it from the same place I get all my other open source software, my distro. A quick "yum search cabal" told me where it was, I grabbed it.

And apparently it was "wrong". Becuase while it's "The Haskell Platform", it's not the correct Haskell Platform.

My point was much simpler than people here are trying to interpret: the Haskell world is a mess, and it's very complicated to get it running. So interesting tools like gitit (which I swear, I really wanted to try) don't get any attention. Expecting your audience to have the same bleeding edge copy of The Haskell Platform as you do is never going to work. Someone needs to actually do the work to package and distribute the software.

This is not true of Perl, or Python, or Ruby, or Node, all of which have recent packaged versions in the distro that run recent software.

I'm not sure that it's the wrong Haskell-Platform, nandemo's remark entails that it isnt. The naive installation would have been `yum install haskell-platform` or whatever, then `cabal update && cabal install gitit` I think you are getting bad advice because this is a completely inappropriate venue and people are having to make judgments on too little information; almost all such problems can be cleared up in 3-4 min on #haskell

You may be right about Perl &co but I invite you to look at my gem installation...

No, I'm pretty sure I have it right: "cabal-install" happens to be the package that contains the cabal binary. I installed that specifically because the instructions on the gitit page start with cabal and skip the Haskell installation; but the dependencies pull it all in automatically anyway. The problem is simply that it's too old, despite being the most recently packaged version on the most recent release of the distro. And the solution to that problem involves building the whole thing, which I'm not willing to do to try gitit.

The haskell-platform package, in every form and version on every platform also contains a cabal binary, see https://admin.fedoraproject.org/community/?package=haskell-p... to see this in fedora. Some of the advice you got here was I think not good because you pretty clearly affirm that you installed the fedora Haskell Platform. On #haskell this could all have been debugged in seconds after the difficulty first appeared.