Thanks, Ignat for bringing this issue! This is indeed a problem in the Haskell community and ecosystem at the moment, and we can't just ignore it if we want to improve things.

Every Haskell developer uses the build tool. This is a crucial piece of development toolchain. That's why it's sad if a core tool is maintained only by a single person, maintainers are not willing to have more open-minded discussions regarding some user-requested features or a tool have poor UX. In my vision, everyone should be welcome to open issues to a build tool and contribute to it as everyone will benefit from improvements. And it's a pity that some people have a negative experience with this process which drives contributors away. I'm following the Cabal issue tracker, so I notice from time to time some not friendly behaviour towards its users.

In the same spirit, having multiple build tools leads to duplication of effort for fixing the same problems and implementing the same features. Writing a build tool requires a colossal amount of effort and time. Not to mention that supporting both build tools is an enormous job as well.

* If your project builds with Cabal, it's not guaranteed to build with Stack (at least you need to write stack.yaml).

* If your project builds with Stack, it's not guaranteed to build with Cabal (you may need to specify upper and lower bounds).

Thus, every maintainer must spend a lot of time maintaining support for both build tools if they want to provide good UX for everyone. I'm doing this for multiple years, and it's a troublesome process, but I do believe that thinking about users first is the way forward. This effort seems redundant in a theoretical world where Haskell has a single, core, official, open-sourced build tool managed by the community.

> I have enjoyed using cabal very much

I'm also using Cabal for my personal projects, but this doesn't mean there are no problems. I learned to circumvent build tools pitfalls and survive in the ocean of incomprehensible errors, but I'm already in the middle of the ocean, and I don't want to stop swimming. Beginners, who are just staying on the coast, might not want to go into it at all.

Best,

Dmitrii

On Thu, 10 Dec 2020 at 14:06, Ignat Insarov via hf-discuss <hf-discuss@haskell.org> 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.
_______________________________________________
hf-discuss mailing list
hf-discuss@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss