[HF-discuss] Do something about Cabal?
Ignat Insarov
kindaro at gmail.com
Thu Dec 10 11:23:42 UTC 2020
# Do something about Cabal?
Hello.
Cabal is the second most used tool in Haskell after GHC. It has many
problems. It may be noticed that there is one and a half developers working on
it. This is clearly not enough to address these problems. I propose that this is
a good place to invest in.
### Problems I have in mind:
* Poor communication, lack of open source development process.
The whole Cabal–Stack schism appears to be an outcome of poor
communication. One of the leading developers of Cabal is even banned from
participation somewhere in Stack circles.[1] Personally, I reported several
issues to Cabal and every single time it resulted in sadness. Observe a
vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
there are fewer contributors ⇒ core developers are overworked.
I have no hard evidence but it appears that presently, more people that strive
to improve the Haskell build experience are outside the Cabal cabal than are
inside.
* User experience is an afterthought.
Cabal's user experience is horrifying. A collection of complaints is being
compiled elsewhere.[2] There are also bugs being opened to Cabal because of
this, requiring triage and therefore wasting the precious time of the few
overworked developers. Stack is much more friendly — this shows by example
that the user experience problem is not inherent and may be solved.
It is ordinary to receive output like this:
```
% cabal run example-executable
Warning: The package list for 'hackage.haskell.org' is 84 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: example-0.1.0.6 (user goal)
[__1] next goal: opaleye (dependency of example)
[__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
config TODO requires ==0.6.7006.1)
[__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
[__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
previous version to fail: excluded by constraint '^>=0.7' from example)
[__1] fail (backjumping, conflict set: example, opaleye)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: opaleye, example
```
There are so many things that are wrong here. Even a sneaky _«to do»_
remark. If you wonder, in this case the solution is to remove and re-generate
`cabal.project.freeze`.
Even the name of the program — it is actually _«cabal-install»_ — is
incomprehensible, it should be re-branded to Cabal, which is how everyone
calls it anyway.
* Features are not being introduced.
There is no reason for two build tools to exist. The killer feature of Stack —
snapshots — should be supported by Cabal. Possibly Cabal itself should be
refactored and split so that there are separate tools for packaging, version
resolution and human interaction — I do not know. But certainly the way things
are presently is a waste of developer effort and a source of confusion for
everyone.
### 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.
* Put in place a clear process for contributing and decision making, so that it
does not come down to the privileged opinion of one of the core developers.
* Make a model of user experience that Cabal should conform to, and make
conformance a priority. Surely there are among us people that know a thing or
two about user experience — call for them to step forward. Every issue that
stems from misunderstanding, re-assign to the model instead of closing.
* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
Stack to join the effort. Transition from Stack to Cabal should be one well
discoverable command that just works.
I realize that this letter is largely an opinion piece. You can also see it as
an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
present. I do not insist that my vision is the best. But the present reality is
not the best vision either. I propose, foremost, that we work and fight for a
better future.
[1]: https://github.com/commercialhaskell/stackage/issues/4472
[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
More information about the hf-discuss
mailing list