I downloaded the latest cabal-install from http://hackage.haskell.org/package/cabal-install and that was a mistake right off.
Assuming you upgraded, you probably had an old version of cabal-install. You should be able to keep using it for the time being. The cabal binary picks up the GHC that's currently in path (or the one you explicitly specify via --with-ghc). There's no requirement to use it with the GHC version that it has been built with.
In fact it's a new install from scratch, no previous ghc. I didn't see why I should install a bunch of stuff I didn't plan on using (I do main development on another machine), but maybe I should have installed the platform first, and then replaced the ghc.
After fiddling around I figured out I apparently need the one bundled with ghc... and sure enough, the source version has a cabal-install-0.13.3.
The current development version is indeed at 0.13.3, but since it's in development, your copy might or might not have the latest patches. The definitive darcs repository for both Cabal and cabal-install is at:
darcs get http://darcs.haskell.org/cabal/
Ah, I'll give that a try as soon as I get back home.
And how are other people testing this out if cabal-install has out of date dependencies? And strangest, why is the 'base' dependency so old?
That's a consequence of how Cabal tries to resolve dependencies. There are multiple flags in the .cabal file (to allow it to build with older or strange configurations), and once the default flag settings fail, Cabal will automatically try other assignments. If all assignments fail, it will complain about the missing dependencies for the flag assignment it tried last. So there isn't really a dependency on such an old version of base.
Thanks for the explanation. I'd seen this kind of behaviour from cabal before, and noted that the constraint does exist under certain flags, but didn't understand how it would choose a particular flag if I didn't pass it.
And while I'm wondering about cabal, why on earth is it that so many Setup.hs files are actually Setup.lhs and with no actual literate contents?
Does it really matter?
It's not of great importance. But it means the Setup names are
unpredictable so using shell history tends to fail, I have to remember
to complete with tab and not automatically type "Setup.hs", simple
shell functions tend to break, etc. I was more curious about how it
happens so much in the first place. My best guess is that someone at
the very beginning had an "everything lhs" style, and then most people
simply copy another project's Setup, so it's a sort of founder's
effect. To be honest it probably mostly piques my sense of tidiness.
On Wed, Feb 1, 2012 at 8:16 AM, Simon Hengel
Are you referring to the classical pattern, that allows you to add a shebang?
#!/usr/bin/env runhaskell
> import Distribution.Simple > main = defaultMain
Ohh, so it's a trick to allow #! in there... I guess that would explain it! I just type runghc on everything and it seems like a lot of those don't have the executable bit set, so I hadn't thought of that reason.