<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>* If your project builds with Cabal, it's not guaranteed to build with Stack (at least you need to write stack.yaml). </div><div>* If your project builds with Stack, it's not guaranteed to build with Cabal (you may need to specify upper and lower bounds). </div><div><br></div><div>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. </div><div><br></div><div>> I have enjoyed using cabal very much</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Dmitrii</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Dec 2020 at 14:06, Ignat Insarov via hf-discuss <<a href="mailto:hf-discuss@haskell.org">hf-discuss@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Francesco. I have also been using Cabal since a long time ago.<br>
There is no question that some great things get done in Cabal. Mostly,<br>
Cabal does what it says on the box, and this is why I propose to<br>
improve it and not, say, move to Stack. But you may see that many<br>
people prefer the latter — this seems even more weird since, as you<br>
illuminate, Cabal can already interoperate with Stackage, so it is<br>
strictly more featureful. _(As far as I follow, Stack still has poor<br>
support for Backpack and sub-package build targets.)_<br>
<br>
However, even in the light of the links you provide, we still cannot<br>
say that Cabal supports Stackage. You say:<br>
<br>
> >   There is no reason for two build tools to exist. The killer feature of Stack —<br>
> >   snapshots — should be supported by Cabal.<br>
><br>
> As far as I know, this is already possible today! [1]<br>
><br>
> [1] <a href="https://github.com/fpco/stackage-server/issues/232" rel="noreferrer" target="_blank">https://github.com/fpco/stackage-server/issues/232</a><br>
>     see also <a href="https://github.com/erikd/jenga/" rel="noreferrer" target="_blank">https://github.com/erikd/jenga/</a><br>
>              <a href="https://hackage.haskell.org/package/stack2cabal" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/stack2cabal</a><br>
<br>
Heading to that link, the closing message says:<br>
<br>
> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.<br>
<br>
So, something is not working. Reading in more detail, there is<br>
evidently a disagreement between the core developers of Cabal and<br>
Stack. And as I understand, it has not been addressed ever since! This<br>
is exactly an example of the kind of communication problems that I<br>
alluded to in my first letter. Also, as far as I can see, there has<br>
been zero effort from the Cabal team to integrate these other tools<br>
that you point to.<br>
_______________________________________________<br>
hf-discuss mailing list<br>
<a href="mailto:hf-discuss@haskell.org" target="_blank">hf-discuss@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss</a><br>
</blockquote></div>