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)
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.
As I user what I would love to have is some sort of FAQ/Migration guide like:
How to setup cabal for a certain stackage-snapshot (including HLS)
How to find/add the right version for a package not in the snapshot (assuming there is one).
How to overwrite with a local version.
How can I get something similar to the scripting with stack.
…
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.
All of these treat stackage as a constraint set of package versions. It’s not an exclusive set.
That’s the point. Cabal is smarter here than stack. It will let you access all the packages from hackage, even those outside of the stackage set and will use a constraint solver to pick those versions that are compatible with the stackage set (compatible in the sense that the version bounds align).
When using stack2cabal, you’d just modify cabal.project.freeze. When using the new import feature, you currently can’t do that. You should download the file manually then as cabal.project.freeze and adjust it.
Boy does this discussion not make me want to learn haskell… just how many tools will I have to learn to get started? I just installed stack and now I’m reading about cabal, GHCUp and whatever else exists.
As in 2022, just use GHCup. It can install Stack if you want to. Here you have a guide on how to set a dev environment. If you use just stack, It is very likely you’ll have problems with the language server protocol
Hello! Stack is a good place to start. Stack is a Haskell build tool. Cabal (the tool) is another build tool, and an alternative place to start. People debate their relative merits for different purposes, which merits have changed over time. Don’t be put off learning Haskell by that debate.
If you use Visual Studio Code as your source code editor, you will want to add its ‘Haskell’ extension (it is excellent). That extension uses something called HLS. HLS is sensitive to the particular version of the compiler, GHC, available to it. Using another application called GHCup to manage things can avoid that complication. That may require a couple of tweaks to Stack’s configuration settings. There is a new page in Stack’s online guide which discusses that.
If you use a different source code editor, I am confident other people here will give you good advice about how to set things up. I happen to use VS Code myself.
Does the cabal stackage snapshot functionality also handle installing the appropriate GHC on a per project basis, or do you have to manually switch GHCs using ghcup when you switch projects?
I recommend ghcup + cabal. Less file formats to learn, less config to change if you want to keep control of your toolchain.
VSCode with cabal and ghcup provide a pretty out of the box experience, similar to what stack does, showcasing how unix tools can be combined to create a holistic experience.
As someone using sometimes Cabal and sometimes Stack, I think it’s an irresponsible – and frankly silly – to say that Stack does not integrate well with HLS, as you do here and in the document you linked. It conveys two misleading beliefs:
that using Stack in production plus HLS / ghcup is particularily difficult (disproportionately more so that using just Stack)
that it’s Stack’s fault for this predicament
Someone with the slightest interest in honesty would say instead:
that the system-ghc setting makes it a breeze to get Stack to work very well with both HLS and ghcup;
that HLS has issues of its own that make it have undesirable interactions with many things (Template Haskell, Tests, etc) – I still love HLS, just saying this en passant
that Stack was designed and shipped way before ghcup, and if I am not mistaken, HLS, and thus cannot be faulted for not “minding” them enough.
I think remarks like these push this thread further in the direction of gaslightning when instead it could create a nice action item for the community (= “let’s help develop stack or else let’s finish implementing stack’s feature in other tools so as to mitigate redundancies and clear the field for newcomers”).
Stacks approach is “batteries included”. It aims to provide a holistic experience. It bundles hpack, has its own GHC installation logic, is tightly linked to stackage.
This conflicts with the “passive integration” approach of the unix philosophy, where you don’t do active integration (e.g. install GHC yourself), but provide passive integration (a user hook that is run before the build with the required GHC version for the build).
Now… as per stack philosophy… it absolutely should install and manage HLS itself. The fact that it doesn’t means that users are forced to use tools like ghcup. And now ghcup authors have to worry about compatibility issues.
So I think it’s fair to say that stack doesn’t integrate well with HLS, because it doesn’t integrate with it at all. That’s fine from a unix philosophy perspective… but stack doesn’t follow unix philosophy.
However, my opinion is: stack shouldn’t integrate with HLS actively. It should reduce such active integrations (compare with docker, nix, etc… I’ve only heard negative things about stacks nix integration).
I’m very uncomfortable reading speculations about the degree to which other commentors are “interested in honesty”. I would prefer such speculations to be left unwritten.
fair enough. It isn’t particularily difficult to configure stack to integrate with HLS. The main problem comes when people don’t know how stack works, and this happens oftenly. Take a look to StackOverflow’s [haskell-stack] tag.
Many questions about Why stack is not building/importing/whatever? can be solve just reading its documentation. Can we blame newcommers of not reading documentation? of course!! but the solution can’t just be go and read 20 minutes about stack/hls nuances. It should be very very clear that stack users do have to have extra caution with the configuration they use: system-ghc + ghcup set ghc x.x.x + snapshot: matching system ghc.
Yes, this is true. It would be ingenious for ghcup – which I think is designed to “oversee” the toolchain, especially when installing stack from ghcup tui – to offer the user the option to edit the global config YAML file, setting system-ghc to True.
