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

Thu Dec 10 19:50:04 UTC 2020

In my view, a lack of communication like the one highlighted here is exactly what the Haskell Foundation hopes to improve. It's still being bootstrapped, so don't expect any action soon, but I would hope for forward motion by the springtime.

Of course, the HF needs all of us to be the best foundation it can -- so please consider nominating yourself for a board position (https://haskell.foundation/board-nominations/) and/or applying for the executive director (full-time, salaried) position (https://haskell.foundation/ed-job-description/)! In either role, you could have direct impact on moving this all forward.

Richard

> On Dec 10, 2020, at 6:42 AM, Allen Sobot via hf-discuss <hf-discuss at haskell.org> wrote:
> 
> 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 <mailto: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 <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> hf-discuss mailing list
> hf-discuss at haskell.org <mailto:hf-discuss at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hf-discuss/attachments/20201210/563bfedd/attachment-0001.html>