[HF-discuss] [Haskell-cafe] Do something about Cabal?

Thu Dec 10 11:42:15 UTC 2020

As a still (very) new Haskell user by many measures, indeed the little experience I had with Cabal isn't great overall in my view (honestly not a fan of Stack grabbing separate GHC instances though either unless I pass like 2 command-line flags, if there's a configuration option I'm not aware of I'd be grateful).

I had no clue about the communication issues etc. plaguing Cabal, that explains a bit...

In any case I'd like to try to contribute what I can to this effort, mainly to improve the UX which I agree is absolutely terrible in my humble opinion.

(Side note: I was informed on another mailing list that I may have some setting pertaining to forcing some kind of read receipt which is considered impolite on mailing lists, if this is still the case I apologize and I'm trying to determine what even is the precise issue or setting controlling it, at least on K-9 Mail and Neomutt)

On December 10, 2020 12:23:42 p.m. GMT+01:00, Ignat Insarov <kindaro at gmail.com> wrote:
># 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
>_______________________________________________
>Haskell-Cafe mailing list
>To (un)subscribe, modify options or view archives go to:
>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>Only members subscribed via the mailman list are allowed to post.