I generally can write Haskell. I’m not especially good at it, I’m definitely not able to tell you how to use a ZygoHistoPremorphism in your code, but fundamentally I find Haskell code relatively comprehensible and there aren’t any blockers to my getting better at it other than time and effort. There’s a lot I like about the language, and I often steal ideas from it for use elsewhere.
And yet I have almost zero inclination to write real code in Haskell, and every time I get a slight hankering to do so this is quickly fixed.
Because the first thing I have to interact with every time I write some Haskell is cabal, and this is enough to cure me of any desire to continue the interaction all on its own.
There are a number of little irritations I have with Cabal. I could get over them. There’s no such thing as a good package manager, only less bad package managers.
But there’s one big thing that I simply cannot get over and prevents me from ever taking Haskell seriously as a platform until it has been fixed.
$ cabal uninstall somepackage cabal: unrecognised command: uninstall (try --help)
This is not just that it’s called one of the many other things people bewilderingly decide is the appropriate name for the uninstall command. cabal genuinely cannot uninstall packages. Further, having the wrong packages installed can leave you in a stuck state where you are unable to develop.
At which point the only fix is “trash your cabal install, rebuild cabal and cabal-install from source” (a process which takes nearly half an hour on my machine, and that’s before I’ve also rebuilt all my dependencies from source).
I understand that this is a hard problem which results from the underlying ghc-pkg infrastructure. I don’t really care.
I also understand that cabal sandboxes are a thing. I don’t care about that either. It helps for development, but you only have to make one mistake or give in to any of the myriad things that are pushing you to do a global install just this one time (binaries, incredibly slow build times, etc) to accidentally destroy your system.
The simple fact is that if the default mode of operation for the primary way of installing packages for your language is “oops, you did the wrong thing. Let me put your system in an inoperable state while you wait for everything to recompile from scratch” then what you have here is not a package manager, it’s a waste of time, and I have enough broken software wasting my time already.
I stand by everything I said in it’s OK for your open source to be shitty. There is no obligation on the part of the maintainers of Cabal, or of GHC, to fix these problems for free. But the fact that it’s OK for software to be shitty doesn’t make it not shitty, and the fact that more than 50% of the time I interact with Cabal I end up in a screaming rage means that I’m just going to not use it unless absolutely forced to, which in turn means that there’s basically zero chance of my ever treating Haskell as a serious development environment.
Edit to add: Brian Mckenna suggested this fix, which is to globally disable the ability to install outside a sandbox. This actually does make sandboxes a viable solution to the problem and is the only thing anyone has suggested that I consider an acceptable workaround. So although I stand by the claim that the cabal infrastructure is terrible, it may now at least be manageably terrible because it can be used without accidentally trashing your system.
I agree, to get stuck in cabal hell is not much fun. What has worked for me is installing whatever package possible by the package manager of my Linux distribution. At least Debian has an impressive list of available Haskell libraries. Also, with the use of stackage (https://www.stackage.org/) the necessity for uninstalls can be greatly reduced. But I admit, cabal uninstall would be a nice thing to have.
Kai: that’s not a solution. Among other factors, it’s widely considered a very bad idea to mix cabal with packages from your system’s package manager, which makes your system packaging Haskell packages suddenly useless the moment you need a single package that isn’t packaged by it.
Also, when you can’t uninstall, the barrier to trying new things is much higher. I find people running dpkg-based systems to be much happier to try new software with long dependency lists than people running RPM-based distributions…
I’m glad stackage exists, but David’s absolutely right, unfortunately. One thing he didn’t rant about is how, if you decide to write Haskell code anyhow and then revisit it a couple years later, you’ll waste a lot of time even getting it to build/run again, for reasons deeply linked to the ones he did rant about…
Has anybody in the Haskell community ever thought about trying to customize OPAM, the OCaml package manager, to be used for Haskell ? OPAM is based on DOSE, a library that provides smart management of dependencies, using external solvers. It has some specific features for OCaml, but I am pretty sure it would’nt be hard to modify it to work with Haskell specific constraints. The Coq community is starting to use OPAM for their own packages.
Hi, if you are in search of a solution that will:
1) Avoid you cabal hell
2) Let you uninstall packages
you can use the nix package manager (you can use in every linux distro, or mac, just to install haskell packages. It sits along your package management).
It lets you declare a list of packages that you want to install, in a file, and manages installation, see for example this gist:
On top of that, it has the last packages *and* binary caches, so that you will also avoid compilation, for the most part.
I reckon, however, that this requires a little investment in learning how the nix infrastructure works, so this may be not everyone’s cup of tea.
Should cabal have a command that does that? Probably.
If by “done” you mean “Cool, you’ve put your system into a new and excitingly different inconsistent state”, then yes. :-p
Confession: I have been using
cabal-installfor years but it is just a wrapper around
I manage to program in Haskell, despite wasting countless hours on “Cabal hell”, so I cannot and will not defend the current state of Haskell packaging, but I do hope it improves, and believe that it is the single worst impediment to Haskell adoption for many people. It’s downright embarrassing having to teach newcomers about Cabal hell and how to work around it.
How is the state inconsistent? There is uncollected garbage, yes. But that’s different from an inconsistent state of the non-garbage data.
Oops, I meant
Got mentioned on reddit, so I thought you might want to read: https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ cabal doesn’t really want to be a package manager (like apt or yum/rug) but rather a build tool like (ant+ivy or maven).
Just wanted to say that the article and comments provide useful information. I was just searching for more info about cabal and possible alternatives, so thanks everyone for providing some useful insights.