GHCUp button on

To me, having a generic (abstract?) start-now button on the Haskell site seems a simple solution: by doing so, the Haskell-site committee can be seen as making the effort to stay “at arms-length” from the controversy, and not “picking favourites”.

Let’s suppose that the Haskell-site committee did replace downloads/ with a GHCUp button as a result of all this - how long would it be before someone else starts another thread with the question:

So, I would like to propose to the community that the GHCUp button be replaced by a link to $ALTERNATIVE instead, which then permits $ALTERNATIVE to be the fount of the Haskell installation and on-boarding experience.

(…whatever $ALTERNATIVE might be) and we all go for yet another “spin” on this burning carnival ride?

Alright, let’s move each option and its associated content to its own page, either on:

  • the option’s own home page (if the associated project has one), or
  • the Haskell web site (or perhaps the wiki site for easier access).

It’s then up to the supporters of each option as to how it should be presented, rather than being a decision for the Haskell-site committee.

As for downloads/, it can then just be a list of URLs to those pages: nothing more, nothing less.

Yes, a big friendly button. Haskell infrastructure can work out the details. I think the important thing is to get community consensus around having one button, and no complicated, alternative instructions.

1 Like

I don’t really know. The decision lies within the committee.

At least one community member referred it back to the community, so they don’t agree taht it is their decision. It is ours if we want this.

And indeed, it got rather heated. I have no further interest in pushing any such agenda.

Ok. To be clear, do you, as the maintainer of GHCUp, think it’s a good idea to have one button taking new users to one page that links to GHCUp. Do you think this would be of benefit to the community?

I have read through some, but I imagine nowhere near all of the advocacy over the years. If the community reached some sort of consensus, it wouldn’t need anything to be advocated or progressed. Everything is working as it should and nothing is stopping the final link in the chain to smooth onboarding.

1 Like

What I am proposing is at odds with this suggestion.

  • this is similar to the status quo, with the downloads page filled with jargon and confusion.
  • it runs counter to the community having a shared and maintained resource, which is, and a consensus that GHCUp is the best option for a single Haskell installation.
  • it is confusing for newcomers, at no benefit to them or to us.

(…whatever $ALTERNATIVE might be) and we all go for yet another “spin” on this burning carnival ride?

The status quo carnival ride that is installing Haskell is what’s burning.

A credible alternative is always welcome, and probable in the long-run. I’m proposing that GHCUp is it right now, and we should make all our lives easier by placing it as the recommended way to install Haskell. It is my recommendation, personally, and I imagine is the majority recommendation.

If there are technical weaknesses, I have yet to hear them, so my conclusion is that the last mile of a single onboarding experience is missing due to social conditions, like something is very stuck in a committee somewhere.

1 Like

I don’t know. Since stack maintainers have shown no interest in improving integration with ghcup, I constantly have to give users support on how to do these things manually: In a ghcup-based setup how to tell stack to use the "recommended" ghc?

I don’t have much capacity these days to deal with these things, so it’s unlikely to improve.

Maybe having added stack support to ghcup was a mistake. But it’s hard to revert that decision now.

I think that reducing the complexity of the downloads page is a worthy goal. Having two download options (GHCup and Stack) is much more complex than having just one. The challenge in this proposal is to get the Stack community to agree to it. If they agree then I think the committee would accept such a change (speaking as a member of the committee).

1 Like

Let’s suppose someone else posted:

So, I would like to humbly ask the community that be replaced by a link to Stack instead, which then permits Stack to form the basis of the Haskell installation and on-boarding experience.

…what would the response be?

As long as the GHCup community came out in favour of it I think that would be fine. Since they are unlikely to this is a moot point. On the other hand I think there is a (very slim) possibility that consensus and trust building work could lead to the Stack community accepting GHCup as the way of installing Stack.

1 Like

I also find it problematic to refer to a specific tool. In my opinion there should also be a hint that you don’t need the tools stack or GHCup at all. This means that the following is sufficient:

  • Install the GHC binary package
  • Download and extract the cabal-install binary package
  • If you are on Windows: Install MSYS2
  • Set environment variables

There are people who prefer a slim installation, even if it requires a little more manual work. However, I would do without exact instructions, as details can change. When I installed Haskell I had to find it myself after being dissatisfied with stack and the haskell-platform. I haven’t tried the way for MacOS.

Look at the bottom of the page: it lists alternative installation options besides Stack and GHCup.

1 Like


first a disclaimer: I have to admit that i did not read everything behind every link here.

As a user I think ghcup is really nice and since onboarding new users (very likely with vs.code) more or less mandates it’s usage anyway I think the decision is already made - right?.

What I did not find out (I probably missed it sorry) is why the stack maintainers are seemingly(?) unwilling to move forward here (I really mean no offence - english is not my first language so sorry if this reads like an accusation).
Is there a technical barrier or do they struggle to find the time?

I really like ghcup and cabal went a long way but for the last years stack(age) never let me down and I’d like to continue using it.


No, there is only said it could be done via an OS package manager, not by manually downloading and installing ghc and cabal-install. Per OS package manager can be problematic because of automatic updates.

I responded in particular to that specific part of the sentence that I quoted which doesn’t mention installing the binary directly but rather asking for alternatives to Stack and GHCup.

And of course you’re free to submit a pull request that lists installing the binary directly as a new alternative option. I’m sure that would be much less controversial than making GHCup the sole default at the top of the page.

Listing the pros and cons of each approach would also be interesting. Of course it shouldn’t bloat the page, but a quick warning about the automatic updates would be nice.

Yes. There were such instructions, but they were removed:

This was discussed already. Numerous times.

In my opinion, native installers and repositories should clearly be preferred over bash scripts downloaded from the internet (even if it is

If we must have a common installer, then having one main option is better than two, but all options should be available on the Download page.

Finally, I I was a bit shocked to read that for native installers, “packages are often out-of-date”. That is simply not true.

1 Like

Neither. There’s a PR that has done all the work. It’s just ignored.

1 Like

ghcup is not a bash script.

Well, executables downloaded from the internet.

1 Like

It absolutely is true:

  1. Debian -- Package Search Results -- ghc
  2. Ubuntu – Package Search Results -- ghc
  3. dev-lang/ghc – Gentoo Packages
  4. Arch Linux - ghc 9.0.2-1 (x86_64)

You don’t download executables via your package manager? Or is it not the internet?