If by “NPM” you mean the Node package manager, then my understanding is that it would have the same issues as cabal-install: it can only manage packages for the language it’s designed for, and thus won’t bring in any non-Node libraries/tools that are needed.

If, however, you mean that it bundles the entire dependency set into one package… then no, we don’t have that for Haskell… and I don’t think anyone is really planning anything like that, as it would be inherently fragile (it would depend rather strongly on the version of GHC you’re using for starters).

It also significantly helps deployment in that I can simply and easily package an application with all requisite libraries, meaning that the environment is almost guaranteed to be constant between development, testing, and production systems.

The only way I can see this being fixed is if GHC creates re-named copies of libraries like containers, etc. and thus the boot libraries that _need_ to ship with GHC (e.g. Cabal, ghc-prim) are munged to work with them; if they don’t expose any types from these re-named libraries then it should then be possible to use separate copies of containers and the like for everything else.

Now, I must admit that I am currently building most of my packages by hand using cabal-install; this is because I mean to add better Haskell support to Exherbo by letting the package manager natively understand .cabal files and get packages straight from Hackage (rather than manually or semi-automatically creating exheres), but that involves C++ hacking, which I’m avoiding :p

Now seriously, in principle I completely agree with this post, and this is what I try to do. But I can see why people switch to hand-building: you install something from your distro, it has a bug. You go ask on cafe, and you’re told: “Oh, but you’re not using my latest-n-greatest! Upgrade now!”

And distros can lag not only when their Haskell support is “bad”, but for fundamental distro-wide reasons. For instance, I track debian testing, which is now frozen. The freeze will take about half a year, going by past releases.
Other similar situations are transitions to a new libc.

I guess the basic problem is that the Haskell world just moves so fast. Faster than just about anything but the Linux kernel. And for the kernel I make an exception: I build my own, because I need the latest hardware support. In a weird way, the lowest and highest level software in a GNU/Linux distro is similar

Even so, one doesn’t always have the luxury of having root access to one’s machine (using Haskell in a non-small company with an actual IT department). It is easy (well, reasonably so) to set up cabal-install to use a local “user” repository. It is impossible (well, nearly so) to do the same for the “system’s package manager”. One could argue this is a fault in the system’s package manager, but it is one that seems to be shared by all of them.

The lack of integration between GHC’s “bootstrap” and cabal-install is another major pain. Consider for example that at the time I am writing this, it is impossible (without an extreme effort, anyway) to get containers-0.5.0.0 to work with GHC 7.4.2. This kind of issue isn’t something that can be solved by having the system’s package manager handle the dependencies, unless one is using a source-based system package manager and without much deeper integration between it and GHC – again, a “non-trivial” undertaking with significant per-distro effort.

Yes, it is true cabal-install can’t handle non-Haskell dependencies, but this doesn’t mean that it wouldn’t be a very useful thing to have a true cabal package manager that works across all distros within these limitations. Ruby’s “gem” command, for example, attempts to be a true package manager, independent of the system’s package manager. While it does have some warts and restrictions due to being unable to handle non-Ruby dependencies, it is still extremely useful.

Bottom line, it would be extremely useful to have a more powerful cabal-install which is better integrated with the GHC “bootstrap”, allowing proper management of Haskell packages.