Shared publicly  - 
Is Cabal one of the two biggest problems for Haskell in production?
Gershom B's profile photoKetil Malde's profile photoMichael Snoyman's profile photoManuel Chakravarty's profile photo
Is it bad or ugly, you mean?  (/me struggles to translate the link into a connection.)
I agree that Cabal has historically been a nightmare, and it still can be very frustrating at times. But I'm happy with a lot of the recent movement going on there, especially the efforts of +Andres Löh. I'm hopeful that in the not-too-distant future, people will look at that slideshow and say, "What's wrong with Cabal?"
Ah, +Manuel Chakravarty, with no obvious links or buttons, I only saw the first slide.  After the "slide set" cue, I now discover I can press right-arrow to move forward.  Current technology is getting too complex for me - and I must be getting too old for it.
c'mon, "ugly" isn't very helpful.  Cabal might not be perfect, but it does some amazing stuff.  It worked flawlessly for all the students last week to install all the packages we were working with - accelerate, accelerate-cuda, criterion, remote, etc.  not a single hitch, and those lead to a lot of dependencies.

Had a really productive discussion last week with +Andres Löh, Duncan Coutts and +Philipp Schuster about his SoC project to allow multiple package instances to be installed together.  The currently evolving document about the design is here:
+Simon Marlow Forgive me - I couldn't resist the reference. Cabal has been a wonderful help, it's just showing some cracks. The talk was mostly based on my experiences running a startup on Haskell and the frustrations I experienced.

The thing I missed most was the idea of a build artifact that can be deployed on a remote host. In Ruby, I get that for free with a Gem lock file. With Cabal, I just get the binary, which means I have to match libraries and architectures.
+Mark Wotton I've talked about having the equivalent to Gem lock files in Cabal with Duncan and he agrees that this is something which we should do. I think we have an idea of what the design should look like as well. We mostly lack the developer time.
We need to get Duncan onto G+ so he can discuss this stuff directly. Peer pressure time!
Though the idea of getting somebody onto a social network in order to be more productive does seem a bit... counterintuitive I suppose :-)
+Simon Marlow Re ”ugly", +Mark Wotton was contrasting what worked for him and what didn't in deploying Haskell software. If Cabal was caused him grief, then that is fair enough.

I'm glad to hear that everything worked out smoothly for your students. Unfortunately, I'm usually not that
Iucky. Getting Haskell software installed on students' machines (usually a mix of Macs, Windows machines, and Linux boxes) is a pain. Every single semester. By now, I usually set a marked exercise along the lines of install GHC and this given list of libraries on your compiler and write a trivial program. This is so that they run into the installation troubles before they need to use the software for a more significant assignment.

The problems are usually varied and arguably often the students fault or due to the particular set up of their machines. However, one fundamental problem is that everything needs to be compiled from source. That just makes everything even more fragile than it is already anyway.
+Manuel Chakravarty  Let's take the specific problem of binary distributions, since that is a complaint in common between you and +Mark Wotton.  Cabal is specifically designed to be a basis for building binary distributions, but the idea is that you build platform-specific support on top of Cabal (of course, since the mechanisms for binary distirbutions are always platform-specific).  The Debian folks have done a good job here, and you can instal prebuilt binary packages for a large chunk of Hackage on Debian and Ubuntu systems.  Other Linux distros have similarly good support.  That the same isn't true on Mac and Windows is sad, but I don't think Cabal is to blame - nobody has stepped up and built the tools or put the effort into maintaining the binary packages.  Furthermore, the Haskell Platform is designed to help with this situation, but it is not seeing enough effort put into new package proposals or help with distribution building.

Many problems that people run into are, as you say, local configuration problems or bugs in the packages themselves (e.g. non-portability or incorrect dependencies).  It would be great if our tools helped you find and fix these problems, but the lack of such features is not really a fundamental problem.

I think it's terribly negative to just blame Cabal for everything. It's a well-designed system, with a couple of serious limitations that are being actively addressed.
+Simon Marlow That's very much focused on libraries, though. For an app developer (particularly webapps), you aren't generally going to be rolling Debian packages just to be deploying new code to your machines.

I do appreciate the work that's been done, and I wouldn't have been able to do my work without Cabal. However, I still spent a fair bit of time I couldn't easily spare recovering from Cabal idiosyncrasies: that's just an experience report, not a value judgment.
Would it help if it were possible to build static binaries?  I'd love to be able to make stuff available as generic "linux" binaries, this would substantially lower the bar for deployment.

I don't quite grok .deb enough to make debian  packages, and that'd still leave all the other distributions out in the cold.  Unfortunately, static linking has been deprecated by the glibc developers, so we'd need to make GHC work with another libc.  They do exist, though, so it shouldn't be entirely impossible.
+Mark Wotton true, I'm thinking mainly about libraries (and to be fair I think Manuel was too).  I don't have any experience with deploying web apps, but is there any reason that the necessary support could not be added, either as part of Cabal or a separate tool?  Is there a good description of the issues, somewhere?  If not, it would help a lot if someone were to write one, and make a concrete proposal.
+Johan Tibell At least on newer Linuxes it doesn't work because glibc doesn't support static linking anymore (I tried just recently).
+Mikhail Glushenkov So you'll have to link libc dynamically (meaning that you need to build on a platform with compatible libc), but you can still link the Haskell code dynamically.
I haven't thoroughly tested it out yet, and it might seem a bit heavy-weight, but CDE ( caught my attention the other day. Basic idea is to package up all of the shared libraries (and other resources) so it can be run on different Linux systems.

I tested on a simple Yesod executable, and the overhead of extra libraries was large, but not overwhelming (I think it was 20-30 mb). I was thinking of testing out a Heroku-based deployment with it to see how it goes.
My experiences moving dynamically linked executables between systems are not encouraging.  Typically, I build on a cutting edge development machine, and deploy on a long-toothed fossil - what IT professionals call an "enterprise" system.  Which will have some glibc from inter-glacial times and consequently won't have any business with my modern executable.

Haskell code is usually linked statically anyway, as far as I can tell - its glibc that's the problem.

Alternatives could be: dietlibc, uClibc, newlib (Red Hat), Bionic (Google), musl.  A partial comparison is here:

Maybe this - that is, making GHC link statically with an alternative libc - would make a good SoC project?  Or is it entirely trivial?

Edit: This page lists some of the tradeoffs in Bionic, it leaves out stuff Java doesn't need (C++ exceptions), presumably, Haskell would be similar?
So google's gonna get into genome search now? :-P
+Johan Tibell you can deploy a static binary. you still need to match architectures, though. I know a lot of these problems seem trivial, but in the space I was working, it's like the death of a thousand cuts. You need to be able to deploy quickly. My benchmark here is not "how hard it used to be" but "how easy is it to deploy a new rails app on heroku", with the answer being "under a minute". For possibly short-lived experiments, this is really helpful.
+Simon Marlow I think it's absolutely possible for Cabal to be improved, and recent developments have at least made it harder to accidentally trash your install. for app development, something like virthualenv or cabal-dev needs to be the default, there's too much overhead in making things work for other devs otherwise.

What format would be best for a listing of problems/extended whinge?
Add a comment...