GHCUp button on www.haskell.org

After reading through another confused newcomer, I’d like to explore Explanation of GHCup vs. stack.

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.

So, I would like to propose to the community that http://www.haskell.org/Downloads be replaced by a link to GHCup instead, which then permits GHCUp to be the fount of the Haskell installation and on-boarding experience.

The tension between component developers is, IMO, largely a fiction, historical or otherwise. If it isn’t, I suggest that airing dirty laundry in our onboarding pipeline as evidenced by a confusing pathchwork of instructions is not a good look for the community.

GHCUp had established trust within the community. Inclusion of hls and stack has been well-engineered and respected. Why have we stopped at the last link and dropped the ball on an easy and complete onboarding pipeline?

This is low-hanging fruit; an easy fix that would immediately help newcomers and those that try and help them.

7 Likes

…how about a generic button labelled e.g. “Get Haskell Now!” which goes to GHCup? That way, if something better that GHCup appears (a Lisp Haskell Machine?) then the change has no observable effect on the Haskell site.

1 Like

Sounds like premature optimization.

I have advocated for that multiple times. The last attempt was here: https://github.com/haskell-infra/www.haskell.org/pull/93

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

The main caveat about stack integration is this PR I submitted https://github.com/commercialhaskell/stack/pull/5585

It has not seen any response from the maintainers. One might argue that unfinished integration is an argument against dropping all other installation instructions.

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

3 Likes

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 haskell.org 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 www.haskell.org, 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 Haskell.org 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 http://www.haskell.org/Downloads 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 Haskell.org-official 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

Hi,

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.

2 Likes

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: https://github.com/haskell-infra/www.haskell.org/pull/194

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 haskell.org).

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.