# yum -y install cabal-install
# cabal update
# cabal install gitit
Resolving dependencies...
cabal: cannot configure old-time-1.1.0.0. It requires base >=4.4 && <5
For the dependency on base >=4.4 && <5 there are these packages: base-4.4.0.0,
base-4.4.1.0, base-4.5.0.0 and base-4.5.1.0. However none of them are
available.
base-4.4.0.0 was excluded because base-4.3.1.0 was selected instead
base-4.4.0.0 was excluded because of the top level dependency base -any
base-4.4.1.0 was excluded because base-4.3.1.0 was selected instead
base-4.4.1.0 was excluded because of the top level dependency base -any
base-4.5.0.0 was excluded because base-4.3.1.0 was selected instead
base-4.5.0.0 was excluded because of the top level dependency base -any
base-4.5.1.0 was excluded because base-4.3.1.0 was selected instead
base-4.5.1.0 was excluded because of the top level dependency base -any
Sigh. "Haskell Platform" indeed. If I can't get it and run it, I
won't try it. Ruby and Python and Perl and Node make this work...
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.
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.
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?
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.
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.
Yes, Ikiwiki was an inspiration to us: besides the goal of supporting multiple revision backends, John also took the idea of caching from it when we ran into performance issues on page loads.
Haskell, for starters. But more seriously, the motivation is to have a wiki with the capabilities of Pandoc: a bunch of formats -> a bunch of other formats. One comment already pointed out literate Haskell, which is nice.
Pandoc is excellent. But it's also available for ikiwiki, since I did a quick port a year ago: <https://github.com/dubiousjim/pandoc-iki>. I don't claim it's (yet) as well-integrated as it is with gitit.
I've used gitit a fair bit for some personal things and I'm very impressed. Unlike doku-wiki it was still lightning fast when running off of an old EeePC 700 (630Mhz Celeron).
I've started implemented a diff-based text storage engine for PostgreSQL. It accomplishes the same principle, but using Postgres as a backend, instead of Git. It's very rough, but I'd love to get some feedback!
How many different ways of hosting a wiki page do we really need? What problem is being solved here that isn't solved by the multitude of similar options? (Not trying to be negative, i'm just trying to understand what problem/pain point is being solved by this tool that hasn't already been addressed)
