
How we might abolish Cabal Hell, part 1 - tux1968
http://www.well-typed.com/blog/2014/09/how-we-might-abolish-cabal-hell-part-1/
======
jordigh
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
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.

~~~
davexunit
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.

~~~
pjmlp
> 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
> 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
_" 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".

------
mswift42
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
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
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.

~~~
sjy
That's not a sandbox problem, that's the cost of developing in an AOT-compiled
language. Sandboxes do require you to recompile Yesod and all its dependencies
(> 10 minutes) every time you start a new project though, which is pretty
annoying.

~~~
dllthomas
I agree that it's not a sandbox problem, but it's not inherent to "an AOT-
compiled language" \- builds of my yesod projects take disproportionately long
compared to my other development, almost all of which takes place in compiled
languages.

------
SuperStache
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?

~~~
munificent
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.

~~~
seagreen
Anyone know if there's a formal name for this situation/problem?

Thanks for the clear explanation BTW.

~~~
tel
You probably would have good vocabulary for this in the _ML family languages.
You 're essentially talking about existential type mismatching—a core
component of how modules work in _ML family languages.

It's just hard to read that into Haskell since "modules" are not as well
represented in-language and exist somewhere between Haskell-the-language and
Cabal-the-package-manager/ecosystem.

------
toolslive
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
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.

------
tieTYT
> 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
>I develop on Windows

In my experience, this sucks in basically any language.

~~~
skrebbel
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_.

~~~
sanderjd
That is definitely impressive of the Node.js community! Good on them. Also
great to know Elixir is working well on Windows, yet another feather in its
increasingly-well-plumed hat!

I remember a get-Windows-working-better rallying call at a Ruby conference I
was at 4 years ago, and as far as I can tell, things have not changed much
since then. The OSX thing isn't quite fair though - everything works on linux
too, because that's what people deploy on. In fact the trend seems to be
toward developing against containers running your production version of linux,
rather than OSX directly.

------
wyager
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.

------
seagreen
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
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
Yes and with ease for the first two. Yes, but you may have to write some Nix
code for the last.

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

------
colemorrison
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...

------
jabberwock
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
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
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
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
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.

