[Haskell-cafe] Do something about Cabal?

Viktor Dukhovni ietf-dane at dukhovni.org
Thu Dec 10 22:53:05 UTC 2020


On Thu, Dec 10, 2020 at 04:23:42PM +0500, Ignat Insarov wrote:

> * User experience is an afterthought.

I don't think that's fair. Making/keeping the simple things easy,
without making the complex things impossible is always a challenge. 

Yes, starting a hello-world project should admittedly be one command
with fewer required options.  Presently, it is:

    $ mkdir hello
    $ cd hello
    $ cabal init --cabal-version=2.4 --license=NONE -p helloworld

but this is not the primary barrier to Cabal's usability.

Like many a tool that has evolved over decades, and supports backwards
compatible historical practices, Cabal exposes more complexity and rough
edges than much more recent toolchains that don't share than burden.

Give me Cabal over Debian packages any day...

>   Cabal's user experience is horrifying. 

It is likely that use of strident terms like "horrifying" does not
further the kind of community building that this message aims to
achieve. :-(

Indeed cabal was fairly intimidating when I started out, and for a long
time I used stack.  More recently I've switched to cabal, as a more
flexible power tool.  And yet some workflows, e.g. involving internal
libraries, custom builds, code generation, doctest integration, ...
remain challenging to figure out.  On the whole, I've seen much progress
over the last few years.

>   It is ordinary to receive output like this:
> 
>   cabal: Could not resolve dependencies:

I would posit that this is the main obstacle facing most users, and is
largely not Cabal's fault.  Rather it is a key property of the Hackage
ecosystem that libraries can and do make incompatible changes across
major version bumps, and that when one chooses a sufficiently new GHC
or elects a sufficiently new feature of some library, the rest of the
ecosystem may not yet be manifestly compatible with that choice.

Stack side-steps the problem by freezing the compiler, base and most
dependencies.  This is often convenient, but is not always what you
want.

I don't see a high likelihood of a second community effort that produces
LTS-style snapshots for cabal, nor that the Cabal and stack teams goals
will align sufficiently to make the snapshot definitions a shared
resource.  Perhaps I'm too cynical, but I think that's the realistic
assessment.

> ### My proposition, in particular.
> 
> * Ask all the people that show compassion to the cause of a great Haskell build
>   tool to unite and work together on a better Cabal. This includes the
>   developers of Stack and everyone that expressed unhappiness with the current
>   state of Cabal. These people should be seen as a blessing, not as an obstacle.

This post seems unlikely to lead to that outcome...  It has probably
already started off on the wrong foot, by being more strident than
constructive.

It all probability reuniting development efforts that have parted ways
is not possible.  All that can happen is that some, but ideally not all
will wither away.  Nobody has succeeded in reuniting NetBSD, OpenBSD and
FreeBSD.  Not to mention the many Linux distributions, screen vs. tmux,
GCC vs. LLVM, KDE vs. Gnome, ...

More realistically, contributors to Cabal willing to devote time and
energy to improving it will add the features that they care about most.
Perhaps now and then someone will step up to *fund* development of some
crucial feature that no volunteer is likely to build on their own
accord.  It all largely boils down to resources, and the fact that
volunteers will work on what most interests them, and there's no
benevolent dictator able to set a global agenda.

-- 
    Viktor.


More information about the Haskell-Cafe mailing list