I just want to show some love and support for the stack maintainers here; I use stack daily; in many projects, and my life would be significantly more frustrating without it. I really appreciate all the effort that has gone into it.
I also appreciate my cabal friends and users and developers.
I believe that we will be able to find a nice way forward, somehow 
mark all older documentation as being deprecated; if it’s possible to do so then augment the meta-data so search engines don’t rank older documentation so prominently.
According to:
https://github.com/commercialhaskell/stack/blob/master/ChangeLog.md#v211both the --resolver and solver options were dropped from Stack, but --resolver appears in the current documentation:
https://docs.haskellstack.org/en/v2.7.5/GUIDE/#resolvers-and-changing-your-compiler-version…was it reinstated?
Until your post, I had not realised that there were old versions of the Stack online documentation available. I’ve always gone (usually via Google) to https://haskellstack.org (which redirects to Home - The Haskell Tool Stack) and had not spotted the small ‘version’ box in the bottom right corner. When people fix the documentation, they are asked to target the stable branch. I do not know where the earlier online versions are picked up from. I’ll see if I can find out.
On stack --resolver=RESOLVER ..., it is available. See also stack --help (… Override resolver in project file).
On the ChangeLog entry for v2.1.1, I can see where it says --solver was dropped but cannot see where it says that --resolver was dropped.
While trying to find the URL again, I found this:
…so it seems the problem with --resolver was only with GHC 8.2.2 - I must have encountered a proverbial “red herring”: apologies for the confusion.
Hi, just chipping in my 2 cents here. I am not familiar with the background history for the past one or two decades, to find the answer to the question as it’s titled (though it seemed more of a rhetorical question), I went on to github and compared the objective metrics:
It seems to be me quite a indisputable answer from an outsider point of view, without knowing about the drama?
Useful, thanks. Bear in mind that the scales are quite different though. You should mentally divide the cabal peaks by more than 3! (200 / 60)
Is there a guide available for the stack-using people how to migrate to cabal? Maybe just to try it out.
I love this idea! I think it can serve as a great touchstone for the claim that Stack workflows can be replicated simply with Cabal. If it’s simple, it should be easy to write a simple guide to explain it!
If it’s simple, it should be easy to write a simple guide to explain it!
And if it isn’t, there would be a list of pain points to mend.
Does Cabal support constraining one’s project with Stackage’s snapshots? To me that’s stack’s killer feature, and I am not able to imagine why anyone would want to step away from stack and no longer be able to use this feature.
You can do it today by copying the stackage snapshot cabal.config files into your projects (e.g. this one for lts-19.16). Linking to these remotely is part of the soon to be released version 3.8 of cabal.
It remains to be seen how well it can deal with packages that are not in the snapshot, and how easy it is to use other versions of packages that are in the snapshot.
It is done and available in 3.8 pre-release (available through ghcup).
What doesn’t work is overwriting constraints. Constraints in cabal.project are simple union. Duncan had a proposal to add a constraint algebra where you can specify how constraint sets are combined. Afaik, no one is working on that. So if you wanted to overwrite specific constraints from the stackage set, you’d have to process it yourself. That’s actually not very hard to write a small script tool for.
Okay, so if Cabal devs are re-implementing stack’s most difference-making features, does it mean that having stack around is to carry a “dead weigh” that’s going to divert newcomers from the real thing, Cabal? It would be unfortunate to cause more fragmentation, even if unintentionally.
In the grand scheme of things, do Cabal devs consider Cabal to be stack's successor? Or would they be interested in Cabal’s being the most salient part of stack’s successor, perhaps by absorbing the two?
Any alternative seems to introduce fragmentation and to make things unclear, as far as Haskell’s toolchain. There many people who use stack, so it would be nice if they had a chance to get some heads-up.
I don’t think so. Cabal devs are simply open to reasonable features like stackage support. Additionally, cabal was there first.
There’s not that much more left though in terms of features to absorb.
What remains is more of a difference in cli experience and default configuration. Those are probably unlikely to change for a while, but are not features per se anyway.
As someone who finds Stack immensely superior in terms of user experience (especially felt that when I started Haskell with a background in more widespread languages), I can only rejoice to that. But I would not mind a merge/absorption either, because that would be justified in case of feature parity)
Well, this is sorta vague and not actionable. That’s the problem.
You’ll notice it’s gonna be hard to come up with a use case that you have with stack that can’t be satisfied by cabal today.
But the opposite is true. There are many use cases stack doesn’t cover:
The only difference is really the experience. Experience depends on interface and default configuration.
By the way, if anyone encounters confusing or bad error messages with cabal. Please report them to https://github.com/haskell/error-messages. I think we have done some good work already, but mainly just on GHC error messages. I would really like to see more reports about cabal error messages, because I’m sure that they are not optimal yet.
Fully agree.
As I user what I would love to have is some sort of FAQ/Migration guide like:
Don’t get me wrong: up to recently (mainly due to the changes with ghcup/hls) I only used stack and it never really let me down (I had no issues with cabal v2 so far but the experience a few years back was really horrible - that’s why I gladly embraced stack back then).
On the other hand as normal ghc user I’d be happy to really only have one build tool. I did not mind changing every so often a while back but with more projects the pain of changing build systems often has gotten *real.
