Explanation of GHCup vs. stack

[tonyday567]

Can we include a clear explanation of when a user would choose:

• installing via GHCup versus installing via stack
• using stack as the primary package manager versus using cabal-install

Thinking through the complexity and how to help new users navigate, I felt it would be difficult to make a good choice on the installation method without understanding the nuances of the basic package management decisions involved.

I note that this is a live topic for the community, and potentially a fresh look at the issues from the perspectiove of a new user:

https://www.reddit.com/r/haskell/comments/tvbrmp/stack_compared_to_cabalinstall/

[tomjaguarpaw]

This is historically a highly contentious issue and as such it should be resolved by the community outside of the auspices of www.haskell.org. Once resolved www.haskell.org can incorporate any content compatible with the resolution. www.haskell.org cannot afford to be seen to take sides in this issue.

[tonyday567]

Thanks, and totally understand this positioning.

Just as a follow up, would you agree that it would be useful for new users to have this information in order to make an informed choice? That absent this information, the Downloads page will never really make sense?

Within this context, I was considering a PR along these lines, a refactoring of the downloads page that made it clear there are two options and explained the differences between them. I imagine it is possible and practical to lay it all out without contention but maybe I'm not quite across the specifics yet. It could be cathartic, even.

Do you have any thoughts on how to usefully progess this?

[jaspervdj]

I think it could make sense to have a page documenting the differences. This page would go out of date occasionally, so it would need regular maintenance from someone who knows both Stack and Cabal very well.

I don't think this page should be the downloads page though. Presenting this information is IMO more likely to overwhelm and confuse newcomers rather than help them get started as easily as possible.

[tomjaguarpaw]

Just as a follow up, would you agree that it would be useful for new users to have this information in order to make an informed choice? That absent this information, the Downloads page will never really make sense?

Yes, absolutely. It seems likely to me that confusion between stack and cabal, and also between stack and ghcup, is a significant bump in the road for new users. I would love the situation to improve but I doubt that this is our "low-hanging fruit". The diplomatic and community-outreach efforts required to resolve this are enormous. Personally I'd rather spend my time on other things, and I would rather the Haskell.org committee were not distracted by such matters at the current time.

Within this context, I was considering a PR along these lines, a refactoring of the downloads page that made it clear there are two options and explained the differences between them. I imagine it is possible and practical to lay it all out without contention but maybe I'm not quite across the specifics yet. It could be cathartic, even.

I think a PR is unlikely to make much progress without prior trust-building groundwork laid in the community. You, or indeed anyone, is welcome to put together such a PR, but I expect the effort to go to waste in the absence of such prior groundwork.

Do you have any thoughts on how to usefully progess this?

Yes, here is what I would do (and may indeed do, but not in the next few months):

• Foster ongoing discussion in the community on the differences between stack and cabal, and stack and ghcup

  The aim of the discussion would be to surface knowledge of the differences and to spread that knowledge. The technical differences are fairly well known but it's still important to resurface them. The social differences are probably more implicit and thus more important to surface. It is important to understand why people use one tool over the other, what they value in the tool they use, and how they interact with the support networks that that tool provides (issue trackers, informal support channels on Haskell forums, etc.). The contemporary discussion on Reddit is an example of this kind of thing, but by "foster ongoing discussion" I mean try to make it a topic of interest across a wide range of community forums over a period of several weeks.

• Widen the debate to discover whether there are any areas in which the differences between the tools can be reduced

  This should be done with a clear understanding of the technical and social differences in mind, so must come after the step above. Examples of reducing the difference include adding Cabal support for Stackage LTS snapshots and having ghcup become an officially-supported installation method for Stack.

• During this process I hope that trust will develop in the community that it is OK to have hard discussions on these topics without generating acrimony (I think this has actually happened organically over the last few years, but there's still some more work to do).

• I hope that one outcome of the process will be a community consensus regarding the different use cases of the different tools and therefore it will become clear and non-contentious how to describe the difference between the tools on www.haskell.org.

This whole process needs to be handled with delicacy, tact and empathy (although I think it's less likely to become contentious than in years gone by).

[ketzacoatl]

I don't think this page should be the downloads page though.

Perhaps we first need a "Getting Started" page? Either refactoring the downloads page into "getting started", or as an adjunct?

Presenting this information is IMO more likely to overwhelm and confuse newcomers rather than help them get started as easily as possible.

Well, we either need to put onboarding haskellers onto a specific, currated path, or we need to explain the options as we go. I think this explanatory content would be ok to link to from a getting started page: "if you need more info in the options, look here". However I think it makes more sense to target a simple and cohesive onboarding experience (but I recognize that is blocked on the "difficulty agreeing" problem as noted in previous comments), so we go in circles.

[tomjaguarpaw]

Perhaps we first need a "Getting Started" page? Either refactoring the downloads page into "getting started", or as an adjunct?

Perhaps we first need a "Getting Started" page? Either refactoring the downloads page into "getting started", or as an adjunct?

I think both of these are a good idea.

[hasufell]

installing via GHCup versus installing via stack

You probably mean "installing GHC via X", where X is either ghcup or stack.

Let's look at it.

Differences

1. exposing toolchain to PATH:
   • stack doesn't give an easy way to expose GHC to PATH... instead you're expected to run ghc, ghci etc. through stack (ghci-8.10.7 doesn't work, instead you need stack exec --resolver ghc-8.10.7 ghci)
   • ghcup gives an easy way to expose the entire toolchain to PATH and also allows to set the "main version" (e.g. ghc -> ghc-8.10.7 symlink)
2. predictibility of install locations
   • stack's GHC install locations are not predictable and not configurable (except for STACK_ROOT). That makes it unsuitable for use cases where another tool wants to actually manage GHC and just use the installation logic. You can however query the compiler bindir via stack path --resolver=ghc-8.10.7 --compiler-bin.
   • ghcup's install locations are predictable, can be explicitly queried via ghcup whereis <tool> <version> and can be customized via ghcup install ghc --isolate=DIR. Additionally, ghcup allows to create toolchain config binary dirs via e.g. ghcup run --ghc 8.10.7 --hls 1.7.0.0 --cabal 3.6.2.0 (this is used heavily by vscode-haskell)
3. managing installations
   • stack doesn't allow to explicitly install and run a particular GHC version. there's no explicit install command... you just run something that requires a particular GHC version and it will be implicitly installed. You can't remove installed GHCs through stack, you'd have to figure out the directories yourself and remove them. There's no cli interface to manage toolchain, it's all implicit in stacks "build this project" functionality.
   • ghcup has a rich cli interface to install specific toolchain versions, remove them, manage symlinks to default versions, garbage collect unused stuff (like documentation, profiling libs, etc.)
4. picking GHC binary distributions:
   • stack follows the method of figuring out your system libtinfo version and other properties to pick a bindist
   • ghcup installs based on platform, distro name and distro version... it doesn't inspect libraries present on your system
5. tool support
   • stack only manages GHC
   • ghcup can manage GHC, cabal, haskell-language-server and... well, stack itself
6. platform support: ghcup has historically supported more platforms (like alpine, armv7, aarch64 linux, darwin M1, 32bit linux, etc.)

So, stack is basically not a cli interface for managing GHC installations. It's a cli interface for building haskell projects and toolchain installation is implicit.

GHCup is a toolchain management tool. Nothing more, nothing less. And it can be used as a building block for other tools, e.g. nvim-lsp-installer or vscode-haskell or vabal or haskell-CI, haskell/actions etc. etc.

Similarities

1. compiling GHC from source: both ghcup and stack allow this, but ghcup is much more flexible here (e.g. can build a cross compiler)
   • stack: https://docs.haskellstack.org/en/stable/yaml_configuration/#building-ghc-from-source-experimental
   • ghcup: https://www.haskell.org/ghcup/guide/#compiling-ghc-from-source and ghcup compile ghc --help
2. both allow to overwrite the logic that picks a binary distribution for you
   • stacks setup-info: https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info
   • ghcup's metadata: https://www.haskell.org/ghcup/guide/#metadata
3. both install msys2 on windows

Intersections and interoperability

So, the interesting questions are:

1. could ghcup use stack to install GHC?
   • the clear answer is: no
2. could stack use ghcup to install GHC?
   • absolutely and there already is a PR that adds support for this: Support custom GHC installation hooks commercialhaskell/stack#5585
   • this would give a major benefit for vscode-haskell and ABI incompatibilities, see ABI mismatches of GHC bindists haskell/haskell-language-server#2865

[hasufell]

Perhaps we first need a "Getting Started" page? Either refactoring the downloads page into "getting started", or as an adjunct?

GHCup already has such a page: https://www.haskell.org/ghcup/steps/

[ostcar]

I am new to haskell. In fact, I have never written a single line of haskell. But It sounds nice, so I want to give it a try. Unfortunately I am using archlinux. So I had to learn, the I should not use package in the archlinux packages but use stack or ghcup instead. So the next step is to find out which of them I should use as a beginner. In the end, I find myself in this github issue.

I understand you intention, that you don't want to say, that one tool is better then the other. But for me as a beginner, the learning curve to write the first line of haskell is very high.

[HtwoO]

There is an annoying stack behaviour: when install-ghc: false is not set in ~/.stack/config.yaml, it tries to download ghc all the time. Like when I run stack path --stack-root to query for the path stack is using.

stack does not work well with ghcup, it seems to know little (nothing?) about ghc installed by ghcup. I haven't found a way to configure stack to use a ghc version installed by ghcup.
I followed https://github.com/haskell/ghcup-hs/blob/master/docs/guide.md#stack-integration , but it just won't use the ghc version I have in my $PATH environment variable. I think it injects the $HOOK_GHC_VERSION variable to the hook script when it runs, but no ghcup installed versions match that and it would try to download the version it wants.

[hasufell]

@HtwoO please open an issue here: https://github.com/haskell/ghcup-hs/issues

This is not about haskell.org.