9 ms·

How we might abolish Cabal Hell, part 1

75 points by tux1968 12y ago

jordigh 12y ago
Why do we keep running into this problem over and over again? Why do we need one package manager per programming language? Why is software distribution so damn hard?
- makmanalp 12y ago
  Because general purpose package managers suck at dealing with the concerns of individual programming languages. E.g. installation paths, virtual environments, different compilation methods, etc. There is also no single cross-platform package manager. Mac has macports and homebrew, windows barely got one, linux has yum, apt and others. As a language designer, you don't want any part in this, you want your code to work. So you make your own. edit: To clarify, I'm suggesting that we're stuck in a local maximum - now that all these systems already exist and have widespread adoption and tool dependency in their own environments, there isn't much of an impetus to use Nix or something similar even though in the grander scheme of things it'd be way nicer.
  - zdw 12y ago
    I think the solution is to separate the problem into two parts - The "puts things on disk" part (posix "install" or a low level tool like dpkg or rpm is most like this) - The "determine what needs to be installed" part, (aptitude, yum) I'm all for a per-language or system version of the latter, but once that's done, you should generate packages installed by the former. Heck, wrap all the commands (cp/mv/install/chmod/chown/etc.) that write stuff to permanent places on disk to actually do "add to a package", give it a basic name/version number, and have the low level tool handle adding/removing it from the system (or multiple systems, or deploy it, etc.). All the dependencies, compatibility, etc. are handled by the higher level system. This gets you the best of both worlds - system level packages, and the ability to install whatever you need. FPM (https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm) is a pretty good example of this philosophy. But, instead, we get every punk ass CPAN descendent spraying it's crap all over the filesystem, needing the whole build environment installed, touching the internet in weird ways that don't guaranteed repeatable behavior, etc. sigh
  - davexunit 12y ago
    Haskell folks seem to be gravitating towards the Nix package manager, which is general-purpose. We need to stop the proliferation of a package manager per programming language and make systems package managers capable of handling the use-cases of pip, bundler, npm, cabal, etc. Nix and Guix are the only 2 general-purpose package managers that I know of that can do it.
    - tel 12y ago
      I don't think it's gravitating "toward" Nix. Many members of the community are trying to use Nix personally and maybe Cabal proposals are inspired by Nix. I don't think the idea today would be that the entire community should move to Nix, however, not by a long shot.
    - pjmlp 12y ago
      > Nix and Guix are the only 2 general-purpose package managers that I know of that can do it. For anyone constrained to GNU/Linux, right?
      - davexunit 12y ago
        > For anyone constrained to GNU/Linux, right? I don't feel constrained by a free software operating system. Besides that, a bunch of people use Nix on OS X. On Windows I suppose you're stuck with the inferior package managers.
        dllthomas 12y ago
        "I don't feel constrained by a free software operating system." I appreciate the sentiment, but there's a substantial difference between "constrained to" and "constrained by".
        pjmlp 12y ago
        There are many other OS out there. Why do people only think of the triad?
      - masklinn 12y ago
  - cschneid 12y ago
    In my local group of haskellers, nixos is taking off as a system level package manager that does virtual envs, and multiple package versions pretty well. I haven't had a chance to play with it, but perhaps a sufficiently smart package manager can do both?
  - npsimons 12y ago
    Because general purpose package managers suck at dealing with the concerns of individual programming languages. E.g. installation paths, virtual environments, different compilation methods, etc. And yet all these nifty package managers can't even seem to get things as simple and long solved as permissions straight. Even autoconf sets permissions better than, say, pip, where I have to remember to check my umask before I "sudo pip install something".
    - deleted 12y ago
      [deleted]
  - 14113 12y ago
    To add to that, the concerns that operating system package managers have are very different from the ones that programming language package managers have. With an operating systems package manager, the focus is on shipping working, uber stable code, which is unlikely to break someones system. This (imho) is due to two different factors: 1) Operating systems have to work, no two ways about it, if your OS is broken, everything else is broken. 2) Users of operating systems are not necessarily experts. If their package manager ships experimental code which breaks their particular system, they don't know how to report the bug to the central OS maintainers. I think this is handled somewhat by having different repositorys with different levels of stability, a la arch linux's [core/extra/community/testing/AUR], however at the end of the day, the main repository must avoid having breaking code. With a programming language package manager, the focus is on having up to date features, and catering towards power users who, if things go wrong, can generally fix them, or at least know how to contact, and how to phrase their requests for assistance. This means that it's generally more acceptable to expect users of a programming language repository to occasionally be served broken code, as defects will be reported more rapidly, and more clearly. I find it interesting comparing the two package managers that I use most often in my day to day computing experience: Cabal, and pacman (Arch linux). Pacman offers a single version of each library per repository, and that version is as stable and tested as the repository requires. This is in keeping with the spirit of an operating system package manager, as it allows power users to install unstable packages from more experimental repositories, but tries to serve as stable code as possible to general users. Contrast that which cabal, which basically offers no stability guarantees, but allows for much more fine grained control over library versions, sandboxing etc. TL;DR In my opinion, OS and Language package managers have goals which are at odds with each other: OS package managers want to maintain stability, Language package managers want to allow for bleeding edge code. The concessions that cabal makes towards stability (versions, sandboxes etc) often cause other problems as well.
- MrBuddyCasino 12y ago
  Some package managers are part of build systems too, e.g. the Maven ecosystem. Now in what language should you write extensions or plugins? There will be djihad.
- Doji 12y ago
  The problem Cabal is trying to solve here is supposedly more difficult than that solved by Gem, Pip, and other package managers. GHC does some kind of cross-library optimization that causes dependency problems in routine situations. I agree we shouldn't have one package manager per language, but I think so far no one package manager has proved sufficiently general and robust to serve all use cases. For example, I think something like Nix would be wonderful for all language communities, but it doesn't run on windows. That immediately takes it out of the running. And as far as I'm aware, all other package mangers would have the same "Hell" problems of cabal because of the GHC optimization mentioned above.
  - freyrs3 12y ago
    It is more difficult. By design Haskell shifts an enormous number of failure modes to compile-time and as such cabal gets an unnecessary amount of blame for library bugs. If you ``pip install`` a package that transitively dependencies on another library where the author has accidently introduced a backwards incompatibility in the API that occurs in 5% of use-cases, pip won't detect the change and will happily install the package and 95% of people will assume no problem exists until they hit a runtime failure. The job that pip has to do is trivial actually. In Haskell if there is an incompatibility that breaks the interface, and in the presence of "wild west" packages there will be, then it will manifest as a compile time build error instead of proceeding.
  - sjy 12y ago
    Not only is the package management problem more difficult, it's not the problem that Cabal (the Common Architecture for Building Applications and Libraries) was intended to solve! cabal-install is not a package manager; it can't uninstall packages or even record which packages it has installed.
- bmurphy1976 12y ago
  Let's not forget they are all garbage from somebody's perspective. I know Python. Would I prefer to write my package manifests in some bastardized Ruby DSL or Python? Of course I'd prefer Python and the Ruby guys would prefer their bastardized DSL. I don't blame them. How do we bridge that gap? Python => Ruby => Python is bad enough. What about M4 or AWK or Makefiles or Haskell or god help us all some shitty custom format ala Puppet? You might as well demand everybody on Earth speak English.
  - lucian1900 12y ago
    > You might as well demand everybody on Earth speak English. That's working out quite well so far.
    - lutusp 12y ago
      >> You might as well demand everybody on Earth speak English. > That's working out quite well so far. Not really. English is a minority language, spoken as a primary language by only about 5.5% of the world's population. http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers http://en.wikipedia.org/wiki/List_of_languages_by_number_of_... One more juicy anecdote: there are more Chinese people learning English right now, than there are English speakers in the U.S..
      - jessaustin 12y ago
        Your postscript seems to confirm GP's point. b^)
        dllthomas 12y ago
        I don't know that that's a sign of it working well...
        lutusp 12y ago
        Not if the students' plan is only to remain competitive with native English speakers. Knowing how to speak English as a second language, for pragmatic reasons, isn't the same as being an English-speaker in the sense of the parent post.
- endgame 12y ago
  I think a lot of it is that people are scared of automake, so they reinvent their own build systems, with varying degrees of badness. Then they claim that theirs is "easy" but they've only done the first half of "simple things should be easy, hard things should be possible". A properly autotooled package offers an amazing level of control about where to put things.
jabberwock 12y ago
I think the Haskell folks would do well to consider a complete rewrite of Cabal and look at something like Leiningen, Npm or even Opam as a base from which they can start with their new version.
- freyrs3 12y ago
  Like many people have pointed out, cabal and npm are not solving the same problem. npm appears to "work" more often because a whole class of problems in Javascript program are deferred to runtime while in Haskell all interfaces have to be compatible, link properly and compile. That's why "cabal hell" is such an imprecise term because on top of the version bound issues it's also used for any and every failure that happens when using cabal, even if it's the library in question that's to blame and not cabal. If you want to consider a similar problem, take 20 interdependent C++ libraries and try to link them into a single application using just version information and see how often that works out of the box.
  - dllthomas 12y ago
    I think that's only a part of it. I think that it's also the case that the Haskell ecosystem has more breaking changes at the root of diamonds in the dependency graph - which isn't something a build tool can solve (or at least isn't something any build tool does solve).
    - sjy 12y ago
      In my experience the dependency graph often has many more nodes as well. I'm not sure if this is because Haskell code is especially reusable or Haskell developers are especially lazy.
      - freyrs3 12y ago
        There is an ambient culture of code reuse at a level I don't see elsewhere, that's one of Haskell's strength's in my opinion. Though it does make certain packaging problems more difficult.
mswift42 12y ago
Cabal is by far the worst thing about Haskell. With no other programming language have I ever had to deal with these difficulties. It made me stop using Haskell.
- tel 12y ago
  Mostly because these difficulties are front-loaded by the Cabal system. Version/implementation conflicts are faced by all other package managers, but most solve the problem by (a) waiting until you notice your program has broken and then (b) suggesting you nuke your package sandbox. Cabal just tells you up front when this will happen which can be annoying. That said, the prior mechanism requires that you notice when version mixes are causing issues.
  - mswift42 12y ago
    I understand that is's a very hard problem to solve, but there has to be something better than the Status Quo. A couple of months ago, I wanted to write a simple Web App using Yesod. The only way to get a working installation of yesod and all the dependencies was by using the sandbox thing. This however meant, that after every code change, you had to wait ~10 secs for the project to rebuild. That doesn't sound like much, but it gets annoying very quickly.
    - tome 12y ago
      Perhaps someone more knowledgeable will chime in, but I don't think there should be any increase in incremental build times just because you're using a sandbox.
      - dllthomas 12y ago
        That sounds correct.
    - carterschonwald 12y ago
      Yesod is infamous for being breakage prone. In fact the author now only supports users installing yesod via stackage rather than Hackage, because stackage forces globally coherent fixed versions for every package in stackage. (Basically that every package should be build able together). If you're doing application dev (rather than lib dev), stackage will help. Or use snap, I've never had build hell with snap. But if yesod works for you, awesome! :-)
tieTYT 12y ago
> The feeling of powerlessness one has when Cabal does not do what one wanted and one does not know how to fix it. I experienced this immediately after I read Learn You A Haskell and it made me give up on the language. I develop on Windows (currently?) and I was passionate about creating my first hobby project in Haskell. But every direction I turned, I ran into an issue where a dependency or transitive dependency expected some linux library to be there and I couldn't install. Maybe I'm just spoiled and need to be more open minded. I come from Java-land where I take "write once run anywhere" for granted. I eventually switched to Clojure but that was unsatisfying for different reasons. I wish there was a language with Haskell's purity and type system but Java's ability to "write once and run anywhere". I think Frege is very close, but I feel uncomfortable learning something with such a small community (damn... I am spoiled).
- wyager 12y ago
  >I develop on Windows In my experience, this sucks in basically any language.
  - AnimalMuppet 12y ago
    Well, I think I agree with you, but that wasn't the GP's point. The point was not that developing on Windows was bad, but that Haskell package management was bad on Windows. The GP was not yet running into the problems that you're referring to.
  - skrebbel 12y ago
    Then your experience is rather limited. As a counter-anecdote, my experience is that Windows is frictionless for developing PHP, Node.JS, C#, Java, Scala, Elixir/Erlang. It's also close-to-first-class for Python. Ruby to a lesser extent, with a lot of the community just assuming you're on OSX, period. I've often been impressed by how, despite the hacky nature of the Node.JS community, a lot of stuff simply just works there. For example, getting PhantomJS, a full-fledged scriptable headless browser, available for a project is a single "npm install" away on all three major OSes.
    - 12y ago
SuperStache 12y ago
I was wondering if someone could explain something to me. I understand the issues involving inconsistent environments, but bad constraints don't really seem like a particularly challenging issue to me. If you have libraries A and B which each require mutually exclusive versions of library C, what is stopping the compiler from adding both versions of library C to the compiled code for A and B to call separately? Obviously this would result in larger binaries and should generate a build/install warning, but it seems like this would solve the overwhelming majority of Cabal's dependency resolution issues. There's clearly something I'm missing since this has been an outstanding issue in Cabal for quite some time. Would someone with a better understanding of GHC/Cabal's compilation/linking/installation steps mind shedding some light on this?
- wpietri 12y ago
  I think that would only work if neither A nor B exposes anything about C. I'm not a Haskell user, but certainly in Scala and Ruby there are plenty of libraries where library consumers see objects from underlying libraries. Suppose C is a JSON library, for example. In my code I fetch a JSON object from A, with library version C1. What happens when I pass that object to library B, which uses C2? Is that an immediate type violation because C1 and C2 are treated as different types? Do you live with runtime failures when, say, B calls a C2 method not in C1? Do you you try to create some sort of magic object conversion and hope that the data isn't too different? Or do you try to require all libraries to describe how to convert data from every version to every other version? Even if the two libraries never interacted and data could be proven never to flow between them, there's a real question as to what version of the library is available from the main code. Despite my concerns, I suspect that you could make this mostly work if you were cavalier about possible runtime errors, because actual conflicts would be rare. But from what I understand of the Haskell community, they're not big on "cross our fingers and hope it works at runtime" approaches.
- munificent 12y ago
  I maintain the package manager for the Dart language. This question comes up all of the time. The problem is that these libraries may interact at runtime: * A gets a value from its version of C. * It passes that to your app. * Your app gives it to B. * B gives it to its incompatible version of C. Haskell may handle this scenario differently because of its type system, but in Dart, this would cause lots of user problems.
toolslive 12y ago
The first thing that needs to be done is to acknowledge its existence. Often Haskell zealots pretend it's not a Cabal problem but a user problem. So this article is indeed a very good start.
- dllthomas 12y ago
  I think it's not "a cabal problem", in the sense of cabal being somehow awful and "doing it wrong" where other systems "do it right". The symptoms are a result of the confluence of a few things (mentioned elsewhere in this discussion), some of which are quite positive, which make the problem substantially harder. Which isn't to say there's no problem, or that nothing could or should be better - I'm glad it's getting attention and I'm glad people have ideas for improvements, though both of those have been true for a while.
npsimons 12y ago
As someone who has tried to compile pandoc from source, I welcome this.
seagreen 12y ago
Nix is getting mentioned a lot in this thread. If anyone's interested in NixOS feel free to email me. I switched to it on my main computer about a month ago and might be able to give some perspective on what it's like. My config is here: https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine
- tomp 12y ago
  Could NIX be used as a language package manager? Does it allow installing on cutting-edge code from random repositories? Can you only download something, without installing it? Can you access multiple versions of the same library from a single "project" (e.g. by using different aliases for different versions)?
  - seagreen 12y ago
    Yes and with ease for the first two. Yes, but you may have to write some Nix code for the last.
wyager 12y ago
I had no idea people were having problems with Cabal! It's always worked very well for me. It seemed like one of the better build systems out there. I suppose a lot of the issue comes from the fact that Cabal is very careful about everything. It seems like most package managers I use have a "try and maybe fail" attitude, while Cabal seems to have more of a "guarantee success or fail" attitude.
colemorrison 12y ago
You know you play too much Destiny when... But seriously. It's so difficult to realize how much of a game changer a great package manager can be. I've never tried Haskell, but is this really THAT much of a problem? I hear so much praise and worship about Haskell...

75 points by tux1968 12y ago

Why do we keep running into this problem over and over again? Why do we need one package manager per programming language? Why is software distribution so damn hard?

makmanalp 12y ago
Because general purpose package managers suck at dealing with the concerns of individual programming languages. E.g. installation paths, virtual environments, different compilation methods, etc. There is also no single cross-platform package manager. Mac has macports and homebrew, windows barely got one, linux has yum, apt and others. As a language designer, you don't want any part in this, you want your code to work. So you make your own. edit: To clarify, I'm suggesting that we're stuck in a local maximum - now that all these systems already exist and have widespread adoption and tool dependency in their own environments, there isn't much of an impetus to use Nix or something similar even though in the grander scheme of things it'd be way nicer.
- zdw 12y ago
  I think the solution is to separate the problem into two parts - The "puts things on disk" part (posix "install" or a low level tool like dpkg or rpm is most like this) - The "determine what needs to be installed" part, (aptitude, yum) I'm all for a per-language or system version of the latter, but once that's done, you should generate packages installed by the former. Heck, wrap all the commands (cp/mv/install/chmod/chown/etc.) that write stuff to permanent places on disk to actually do "add to a package", give it a basic name/version number, and have the low level tool handle adding/removing it from the system (or multiple systems, or deploy it, etc.). All the dependencies, compatibility, etc. are handled by the higher level system. This gets you the best of both worlds - system level packages, and the ability to install whatever you need. FPM (https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm) is a pretty good example of this philosophy. But, instead, we get every punk ass CPAN descendent spraying it's crap all over the filesystem, needing the whole build environment installed, touching the internet in weird ways that don't guaranteed repeatable behavior, etc. sigh
- davexunit 12y ago
  Haskell folks seem to be gravitating towards the Nix package manager, which is general-purpose. We need to stop the proliferation of a package manager per programming language and make systems package managers capable of handling the use-cases of pip, bundler, npm, cabal, etc. Nix and Guix are the only 2 general-purpose package managers that I know of that can do it.
  - tel 12y ago
    I don't think it's gravitating "toward" Nix. Many members of the community are trying to use Nix personally and maybe Cabal proposals are inspired by Nix. I don't think the idea today would be that the entire community should move to Nix, however, not by a long shot.
  - pjmlp 12y ago
    > Nix and Guix are the only 2 general-purpose package managers that I know of that can do it. For anyone constrained to GNU/Linux, right?
    - davexunit 12y ago
      > For anyone constrained to GNU/Linux, right? I don't feel constrained by a free software operating system. Besides that, a bunch of people use Nix on OS X. On Windows I suppose you're stuck with the inferior package managers.
      - dllthomas 12y ago
        "I don't feel constrained by a free software operating system." I appreciate the sentiment, but there's a substantial difference between "constrained to" and "constrained by".
      - pjmlp 12y ago
        There are many other OS out there. Why do people only think of the triad?
    - masklinn 12y ago
- cschneid 12y ago
  In my local group of haskellers, nixos is taking off as a system level package manager that does virtual envs, and multiple package versions pretty well. I haven't had a chance to play with it, but perhaps a sufficiently smart package manager can do both?
- npsimons 12y ago
  Because general purpose package managers suck at dealing with the concerns of individual programming languages. E.g. installation paths, virtual environments, different compilation methods, etc. And yet all these nifty package managers can't even seem to get things as simple and long solved as permissions straight. Even autoconf sets permissions better than, say, pip, where I have to remember to check my umask before I "sudo pip install something".
  - deleted 12y ago
    [deleted]
- 14113 12y ago
  To add to that, the concerns that operating system package managers have are very different from the ones that programming language package managers have. With an operating systems package manager, the focus is on shipping working, uber stable code, which is unlikely to break someones system. This (imho) is due to two different factors: 1) Operating systems have to work, no two ways about it, if your OS is broken, everything else is broken. 2) Users of operating systems are not necessarily experts. If their package manager ships experimental code which breaks their particular system, they don't know how to report the bug to the central OS maintainers. I think this is handled somewhat by having different repositorys with different levels of stability, a la arch linux's [core/extra/community/testing/AUR], however at the end of the day, the main repository must avoid having breaking code. With a programming language package manager, the focus is on having up to date features, and catering towards power users who, if things go wrong, can generally fix them, or at least know how to contact, and how to phrase their requests for assistance. This means that it's generally more acceptable to expect users of a programming language repository to occasionally be served broken code, as defects will be reported more rapidly, and more clearly. I find it interesting comparing the two package managers that I use most often in my day to day computing experience: Cabal, and pacman (Arch linux). Pacman offers a single version of each library per repository, and that version is as stable and tested as the repository requires. This is in keeping with the spirit of an operating system package manager, as it allows power users to install unstable packages from more experimental repositories, but tries to serve as stable code as possible to general users. Contrast that which cabal, which basically offers no stability guarantees, but allows for much more fine grained control over library versions, sandboxing etc. TL;DR In my opinion, OS and Language package managers have goals which are at odds with each other: OS package managers want to maintain stability, Language package managers want to allow for bleeding edge code. The concessions that cabal makes towards stability (versions, sandboxes etc) often cause other problems as well.
MrBuddyCasino 12y ago
Some package managers are part of build systems too, e.g. the Maven ecosystem. Now in what language should you write extensions or plugins? There will be djihad.
Doji 12y ago
The problem Cabal is trying to solve here is supposedly more difficult than that solved by Gem, Pip, and other package managers. GHC does some kind of cross-library optimization that causes dependency problems in routine situations. I agree we shouldn't have one package manager per language, but I think so far no one package manager has proved sufficiently general and robust to serve all use cases. For example, I think something like Nix would be wonderful for all language communities, but it doesn't run on windows. That immediately takes it out of the running. And as far as I'm aware, all other package mangers would have the same "Hell" problems of cabal because of the GHC optimization mentioned above.
- freyrs3 12y ago
  It is more difficult. By design Haskell shifts an enormous number of failure modes to compile-time and as such cabal gets an unnecessary amount of blame for library bugs. If you ``pip install`` a package that transitively dependencies on another library where the author has accidently introduced a backwards incompatibility in the API that occurs in 5% of use-cases, pip won't detect the change and will happily install the package and 95% of people will assume no problem exists until they hit a runtime failure. The job that pip has to do is trivial actually. In Haskell if there is an incompatibility that breaks the interface, and in the presence of "wild west" packages there will be, then it will manifest as a compile time build error instead of proceeding.
- sjy 12y ago
  Not only is the package management problem more difficult, it's not the problem that Cabal (the Common Architecture for Building Applications and Libraries) was intended to solve! cabal-install is not a package manager; it can't uninstall packages or even record which packages it has installed.
bmurphy1976 12y ago
Let's not forget they are all garbage from somebody's perspective. I know Python. Would I prefer to write my package manifests in some bastardized Ruby DSL or Python? Of course I'd prefer Python and the Ruby guys would prefer their bastardized DSL. I don't blame them. How do we bridge that gap? Python => Ruby => Python is bad enough. What about M4 or AWK or Makefiles or Haskell or god help us all some shitty custom format ala Puppet? You might as well demand everybody on Earth speak English.
- lucian1900 12y ago
  > You might as well demand everybody on Earth speak English. That's working out quite well so far.
  - lutusp 12y ago
    >> You might as well demand everybody on Earth speak English. > That's working out quite well so far. Not really. English is a minority language, spoken as a primary language by only about 5.5% of the world's population. http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers http://en.wikipedia.org/wiki/List_of_languages_by_number_of_... One more juicy anecdote: there are more Chinese people learning English right now, than there are English speakers in the U.S..
    - jessaustin 12y ago
      Your postscript seems to confirm GP's point. b^)
      - dllthomas 12y ago
        I don't know that that's a sign of it working well...
      - lutusp 12y ago
        Not if the students' plan is only to remain competitive with native English speakers. Knowing how to speak English as a second language, for pragmatic reasons, isn't the same as being an English-speaker in the sense of the parent post.
endgame 12y ago
I think a lot of it is that people are scared of automake, so they reinvent their own build systems, with varying degrees of badness. Then they claim that theirs is "easy" but they've only done the first half of "simple things should be easy, hard things should be possible". A properly autotooled package offers an amazing level of control about where to put things.

jabberwock 12y ago

I think the Haskell folks would do well to consider a complete rewrite of Cabal and look at something like Leiningen, Npm or even Opam as a base from which they can start with their new version.

freyrs3 12y ago
Like many people have pointed out, cabal and npm are not solving the same problem. npm appears to "work" more often because a whole class of problems in Javascript program are deferred to runtime while in Haskell all interfaces have to be compatible, link properly and compile. That's why "cabal hell" is such an imprecise term because on top of the version bound issues it's also used for any and every failure that happens when using cabal, even if it's the library in question that's to blame and not cabal. If you want to consider a similar problem, take 20 interdependent C++ libraries and try to link them into a single application using just version information and see how often that works out of the box.
- dllthomas 12y ago
  I think that's only a part of it. I think that it's also the case that the Haskell ecosystem has more breaking changes at the root of diamonds in the dependency graph - which isn't something a build tool can solve (or at least isn't something any build tool does solve).
  - sjy 12y ago
    In my experience the dependency graph often has many more nodes as well. I'm not sure if this is because Haskell code is especially reusable or Haskell developers are especially lazy.
    - freyrs3 12y ago
      There is an ambient culture of code reuse at a level I don't see elsewhere, that's one of Haskell's strength's in my opinion. Though it does make certain packaging problems more difficult.

mswift42 12y ago

Cabal is by far the worst thing about Haskell. With no other programming language have I ever had to deal with these difficulties. It made me stop using Haskell.

tel 12y ago
Mostly because these difficulties are front-loaded by the Cabal system. Version/implementation conflicts are faced by all other package managers, but most solve the problem by (a) waiting until you notice your program has broken and then (b) suggesting you nuke your package sandbox. Cabal just tells you up front when this will happen which can be annoying. That said, the prior mechanism requires that you notice when version mixes are causing issues.
- mswift42 12y ago
  I understand that is's a very hard problem to solve, but there has to be something better than the Status Quo. A couple of months ago, I wanted to write a simple Web App using Yesod. The only way to get a working installation of yesod and all the dependencies was by using the sandbox thing. This however meant, that after every code change, you had to wait ~10 secs for the project to rebuild. That doesn't sound like much, but it gets annoying very quickly.
  - tome 12y ago
    Perhaps someone more knowledgeable will chime in, but I don't think there should be any increase in incremental build times just because you're using a sandbox.
    - dllthomas 12y ago
      That sounds correct.
  - carterschonwald 12y ago
    Yesod is infamous for being breakage prone. In fact the author now only supports users installing yesod via stackage rather than Hackage, because stackage forces globally coherent fixed versions for every package in stackage. (Basically that every package should be build able together). If you're doing application dev (rather than lib dev), stackage will help. Or use snap, I've never had build hell with snap. But if yesod works for you, awesome! :-)

tieTYT 12y ago

> The feeling of powerlessness one has when Cabal does not do what one wanted and one does not know how to fix it. I experienced this immediately after I read Learn You A Haskell and it made me give up on the language. I develop on Windows (currently?) and I was passionate about creating my first hobby project in Haskell. But every direction I turned, I ran into an issue where a dependency or transitive dependency expected some linux library to be there and I couldn't install. Maybe I'm just spoiled and need to be more open minded. I come from Java-land where I take "write once run anywhere" for granted. I eventually switched to Clojure but that was unsatisfying for different reasons. I wish there was a language with Haskell's purity and type system but Java's ability to "write once and run anywhere". I think Frege is very close, but I feel uncomfortable learning something with such a small community (damn... I am spoiled).

wyager 12y ago
>I develop on Windows In my experience, this sucks in basically any language.
- AnimalMuppet 12y ago
  Well, I think I agree with you, but that wasn't the GP's point. The point was not that developing on Windows was bad, but that Haskell package management was bad on Windows. The GP was not yet running into the problems that you're referring to.
- skrebbel 12y ago
  Then your experience is rather limited. As a counter-anecdote, my experience is that Windows is frictionless for developing PHP, Node.JS, C#, Java, Scala, Elixir/Erlang. It's also close-to-first-class for Python. Ruby to a lesser extent, with a lot of the community just assuming you're on OSX, period. I've often been impressed by how, despite the hacky nature of the Node.JS community, a lot of stuff simply just works there. For example, getting PhantomJS, a full-fledged scriptable headless browser, available for a project is a single "npm install" away on all three major OSes.
  - 12y ago

SuperStache 12y ago

I was wondering if someone could explain something to me. I understand the issues involving inconsistent environments, but bad constraints don't really seem like a particularly challenging issue to me. If you have libraries A and B which each require mutually exclusive versions of library C, what is stopping the compiler from adding both versions of library C to the compiled code for A and B to call separately? Obviously this would result in larger binaries and should generate a build/install warning, but it seems like this would solve the overwhelming majority of Cabal's dependency resolution issues. There's clearly something I'm missing since this has been an outstanding issue in Cabal for quite some time. Would someone with a better understanding of GHC/Cabal's compilation/linking/installation steps mind shedding some light on this?

wpietri 12y ago
I think that would only work if neither A nor B exposes anything about C. I'm not a Haskell user, but certainly in Scala and Ruby there are plenty of libraries where library consumers see objects from underlying libraries. Suppose C is a JSON library, for example. In my code I fetch a JSON object from A, with library version C1. What happens when I pass that object to library B, which uses C2? Is that an immediate type violation because C1 and C2 are treated as different types? Do you live with runtime failures when, say, B calls a C2 method not in C1? Do you you try to create some sort of magic object conversion and hope that the data isn't too different? Or do you try to require all libraries to describe how to convert data from every version to every other version? Even if the two libraries never interacted and data could be proven never to flow between them, there's a real question as to what version of the library is available from the main code. Despite my concerns, I suspect that you could make this mostly work if you were cavalier about possible runtime errors, because actual conflicts would be rare. But from what I understand of the Haskell community, they're not big on "cross our fingers and hope it works at runtime" approaches.
munificent 12y ago
I maintain the package manager for the Dart language. This question comes up all of the time. The problem is that these libraries may interact at runtime: * A gets a value from its version of C. * It passes that to your app. * Your app gives it to B. * B gives it to its incompatible version of C. Haskell may handle this scenario differently because of its type system, but in Dart, this would cause lots of user problems.

toolslive 12y ago

The first thing that needs to be done is to acknowledge its existence. Often Haskell zealots pretend it's not a Cabal problem but a user problem. So this article is indeed a very good start.

dllthomas 12y ago
I think it's not "a cabal problem", in the sense of cabal being somehow awful and "doing it wrong" where other systems "do it right". The symptoms are a result of the confluence of a few things (mentioned elsewhere in this discussion), some of which are quite positive, which make the problem substantially harder. Which isn't to say there's no problem, or that nothing could or should be better - I'm glad it's getting attention and I'm glad people have ideas for improvements, though both of those have been true for a while.

npsimons 12y ago

As someone who has tried to compile pandoc from source, I welcome this.

seagreen 12y ago

Nix is getting mentioned a lot in this thread. If anyone's interested in NixOS feel free to email me. I switched to it on my main computer about a month ago and might be able to give some perspective on what it's like. My config is here: https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine

tomp 12y ago
Could NIX be used as a language package manager? Does it allow installing on cutting-edge code from random repositories? Can you only download something, without installing it? Can you access multiple versions of the same library from a single "project" (e.g. by using different aliases for different versions)?
- seagreen 12y ago
  Yes and with ease for the first two. Yes, but you may have to write some Nix code for the last.

wyager 12y ago

I had no idea people were having problems with Cabal! It's always worked very well for me. It seemed like one of the better build systems out there. I suppose a lot of the issue comes from the fact that Cabal is very careful about everything. It seems like most package managers I use have a "try and maybe fail" attitude, while Cabal seems to have more of a "guarantee success or fail" attitude.

colemorrison 12y ago

You know you play too much Destiny when... But seriously. It's so difficult to realize how much of a game changer a great package manager can be. I've never tried Haskell, but is this really THAT much of a problem? I hear so much praise and worship about Haskell...