While I understand your idea… I’m not sure what you mean with “deprecate”? Who would deprecate stack? Only the maintainers can do that… and even if they do, their users might decide to just fork and keep maintaining it.
There’s no collective decision to be made about it. The only decision a community can do is where to put effort in, maybe what ideas to promote. But that’s about it.
As long as stack has a strong user base and is in a usable state, ghcup will support it (despite the problems it causes for HLS and VSCode).
Well yeah the HF, Stack maintainers (who I understand are all volunteers now), and Cabal maintainers can sit down and come to a big agreement. The deprecation message would be something like be:
We the stack maintainers are retiring Stack.
Stack has been an excellent project that pushed the Haskell ecosystem forward in many ways, but by this point in 2023 cabal / GHCUP have now caught up and implemented what we think are all the core features Stack pioneered. Furthermore, there are a number of other new features (Backpack, multiple public libraries, etc.) that would be quite difficult to implement in Stack.
At this point, we no longer think the community needs Stack to push it along; our major points have been made and are no longer controversial. We thus are officially retiring Stack because it doesn’t make sense to maintain two separate tools which no longer have any major disagreements.
Does Cabal natively support package.yaml and hpack? The reason I still use Stack is that I simply set the resolver in stack.yaml and via package.yaml have hpack automatically generate dependencies in cabal. This is why I’ve always recommended Stack over Cabal especially for new users. Also, Stack automatically resolving and managing GHC version is one less burden new users have to deal with delving into the world of Haskell. I’d be truly upset if Stack falls by the wayside because I still don’t think Cabal meets many of the use cases that make Stack so seamless and intuitive, especially for new users.
If anyone spots something wrong in the Stack documentation, please do raise an issue in the repository (or bring an existing issue to my attention). Those are the sort of issues I can usually fix myself. The exception is where they are specific to Unix-like operating systems (a recent issue about ‘Nix flakes’ being an example).
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.
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.
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:
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!
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.
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.
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.
