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

[YueCompl]

Just my 2 cents of thoughts, no tool can be perfect, as human individuals. If the Haskell ecosystem can be considered a public asset of all users, contributors, it is not wise for us as the stakeholders to be adverse  of competition. Just imagine the government allowing a single military contractor to monopolize a whole category of weapons, what would come after?

Innovation and advancing comes after competition, why shouldn't we embrace that wrt the tooling of Haskell? Duplication in efforts is a relative smaller problem IMHO.

Sincerely,
Compl


> On 2020-12-11, at 05:07, Jack Kelly via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> 
> Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:
> 
> - Can't do GHCjs
> - Seems to like mass-rebuilding my work projects if I breathe on them the wrong way
> - Has its own way of doing everything that's slightly different (different command set, different ways of specifying build targets)
> - Fails to give me a REPL if it can't load all of a target's files first (I'm not sure exactly what's going on here, but when using dante, stack will blow up if the project contains a type error somewhere. Which is unhelpful when trying to get interactive editor support to resolve said type errors! Dante driving cabal does not have this problem. Extremely frustrating.)
> - Haskell programmers tend to end up coding to the lowest common subset of features across build tools. This held back adoption of backpack, which is sad.
> - hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)
> - Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).
> - What is casa.fpcomplete.com, and why was its downtime causing CI failures in my projects? What does stack talk to that domain about?
> 
> HTH,
> 
> -- Jack
> 
> December 11, 2020 12:17 AM, "J Ho via hf-discuss" <hf-discuss at haskell.org> wrote:
> 
>> What's wrong with Stack though? Works like a charm in all our projects, and with Nix integration
>> takes care of the external c-libs etc dependencies quite nicely.
>> 
>> On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <kindaro at gmail.com> wrote:
>> 
>>> Thanks Francesco. I have also been using Cabal since a long time ago.
>>> There is no question that some great things get done in Cabal. Mostly,
>>> Cabal does what it says on the box, and this is why I propose to
>>> improve it and not, say, move to Stack. But you may see that many
>>> people prefer the latter — this seems even more weird since, as you
>>> illuminate, Cabal can already interoperate with Stackage, so it is
>>> strictly more featureful. _(As far as I follow, Stack still has poor
>>> support for Backpack and sub-package build targets.)_
>>> 
>>> However, even in the light of the links you provide, we still cannot
>>> say that Cabal supports Stackage. You say:
>>> 
>>>>> There is no reason for two build tools to exist. The killer feature of Stack —
>>>>> snapshots — should be supported by Cabal.
>>>> 
>>>> As far as I know, this is already possible today! [1]
>>>> 
>>>> [1] https://github.com/fpco/stackage-server/issues/232
>>>> see also https://github.com/erikd/jenga/
>>>> https://hackage.haskell.org/package/stack2cabal
>>> 
>>> Heading to that link, the closing message says:
>>> 
>>>> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.
>>> 
>>> So, something is not working. Reading in more detail, there is
>>> evidently a disagreement between the core developers of Cabal and
>>> Stack. And as I understand, it has not been addressed ever since! This
>>> is exactly an example of the kind of communication problems that I
>>> alluded to in my first letter. Also, as far as I can see, there has
>>> been zero effort from the Cabal team to integrate these other tools
>>> that you point to.
>>> _______________________________________________
>>> 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.
> _______________________________________________
> 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.