[HF-discuss] [Haskell-cafe] Do something about Cabal?
Alberto G. Corona
agocorona at gmail.com
Fri Dec 11 10:35:37 UTC 2020
I played some time ago with a "brute force" building tool which starts only
from the includes of the main source file. It tried to find the packages
for these modules using the google search service to search in Hackage,
download the package sources from Hackage and added the packages as
options to the ghc -ipackage1 ipackage2 command line, recursively. If
some error happened I tried with the files of an older version for the
package that produced the error, by parsing the GHC errors. It failed at
some C import libraries but at this moment it can be switched to build in
cabal or stack mode for that package/module.
I write this just in case this gives some ideas to someone to go along
these lines.
Much of that is what Cabal does anyway, but constrained by the limits
imposed by the *.cabal files in the packages. But the machinery is there
Perhaps Cabal could have a --bruteforce option?
El jue, 10 dic 2020 a las 12:25, Ignat Insarov (<kindaro at gmail.com>)
escribió:
> # 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.
--
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hf-discuss/attachments/20201211/d95fe0ca/attachment.html>
More information about the hf-discuss
mailing list