Moving towards single installer

[tomjaguarpaw]

Currently the Downloads page has the following instructions:

1. Install GHC, cabal-install and haskell-language-server via GHCup
2. To install Stack, follow the Stack installation guide

It has been remarked elsewhere that this situation is undesirable. It would be much simpler and more friendly to have a big "Get Haskell" button. I'd like to move forwards towards that goal.

The first step is to identify what is the difference between the GHCup and Stack installers. Here is my current best understanding:

---

Stack installer

• Can install Stack and GHC
• By default installs Stack (I'm not sure if it installs GHC upfront or if Stack installs GHC only as required by the user's packages)
• Doesn't install Cabal or HLS
• GUI installer on Windows, CLI installer otherwise.
• Installs GHC from official upstream bindists

GHCup installer

• Can install GHCup, GHC, Cabal, Stack and HLS
• By default installs GHCup, GHC and Cabal
• CLI/TUI installer
• Installs GHC, Cabal and HLS from upstream bindists
• Does it install Stack from upstream bindists? If not, which bindist is it using?

---

There are three requirements to "merge" the functionality of these installers (but I think only a subset is worth doing) into a universal installer:

1. Ensure that the installer installs Stack from upstream bindists otherwise Stack maintainers might get bug reports from a bindist they don't support (perhaps GHCup already does this, I'm not sure)
2. Ensure that the installer installs GHC, Cabal and Stack by default
3. Ensure that the installer has CLI and GUI functionality on Windows

Personally I don't see much value in supporting 3. I think we can achieve a satisfactory universal installer by making sure GHCup achieves 1 and 2. Perhaps it already satisfies 1. Satisfying 2 should be technically easy.

I would be interested in technical feedback on this idea, particularly from @hasufell. If it looks like GHCup can achieve 1 and 2 technically then with a bit of work I think we can achieve a consensus that that is the way forward.

---

References

• https://discourse.haskell.org/t/ghcup-button-on-www-haskell-org/4765

[hasufell]

Ensure that the installer installs Stack from upstream bindists otherwise Stack maintainers might get bug reports from a bindist they don't support (perhaps GHCup already does this, I'm not sure)

Not possible at the moment since stack maintainers don't build aarch64 macos binaries at the moment, which GHCup developers build on GHC Gitlab CI.

Ensure that the installer installs GHC, Cabal and Stack by default

This will be done once the stack GHC install hook is integrated with GHCup, see https://gitlab.haskell.org/haskell/ghcup-hs/-/merge_requests/285

[tomjaguarpaw]

Not possible at the moment since stack maintainers don't build aarch64 macos binaries at the moment, which GHCup developers build on GHC Gitlab CI.

I see. So does GHCup use official bindists for architectures other than aarch64?

This will be done once the stack GHC install hook is integrated with GHCup

Nice!

[hasufell]

I see. So does GHCup use official bindists for architectures other than aarch64?

If they work well, otherwise no.

I reserve the right to use whatever bindist works best, whether that's official or not.

Every good distribution channel does that.

[tomjaguarpaw]

That's good, because working well is indeed the point. I foresee no problems as long as there's general agreement about what working well means.

[hasufell]

I foresee no problems as long as there's general agreement about what working well means.

I don't really understand what you're trying to get at.

[tomjaguarpaw]

What would you like me to clarify further?

[hasufell]

What would you like me to clarify further?

I'm just saying I don't understand what you're implying or suggesting.

GHCup maintainers have their workflow and principles. These will only change if there are good technical arguments for it.

[tomjaguarpaw]

Perhaps I can rewind a bit. One of my points above was

Ensure that the installer installs Stack from upstream bindists otherwise Stack maintainers might get bug reports from a bindist they don't support (perhaps GHCup already does this, I'm not sure)

I think it would be very unfortunate if users came to the www.haskell.org website, followed its instructions to install Stack, but the bindist of Stack thus installed was an unofficial one containing bugs, because then the users would get a poor impression of Stack, and the maintainers of Stack would receive bug reports about things that are not their responsibility. If that occurred it would risk reopening an old wound that is currently in the process of healing, but not quite yet fully healed. That would be a problem.

Currently there is no risk of the above happening, because the instructions on www.haskell.org recommend using the Stack official installation guide, so anything that happens following those instructions is the responsibility of the Stack maintainers.

If www.haskell.org switches to recommending GHCup as the way to obtain Stack, and Stack is (sometimes) provided by unofficial bindists, then there is a risk of the above happening.

You say that "I reserve the right to use whatever bindist works best, whether that's official or not.". Is your opinion of what bindist works best guaranteed not to cause the above-mentioned problems for Stack and its maintainers?

[hasufell]

I think it would be very unfortunate if users came to the www.haskell.org website, followed its instructions to install Stack, but the bindist of Stack thus installed was an unofficial one containing bugs, because then the users would get a poor impression of Stack, and the maintainers of Stack would receive bug reports about things that are not their responsibility. If that occurred it would risk reopening an old wound that is currently in the process of healing, but not quite yet fully healed. That would be a problem.

Currently ghcup has fixed bugs in upstream bindists and has never introduced new bugs.

So I'm not sure where your concern comes from.

However, it seems you're assuming that we apply code changes downstream. That has never happened either. I'm hesitant to give hard guarantees about this, but it's unlikely to happen.

Further, I'm a contributor to stack:

• https://github.com/commercialhaskell/stack/pulls?q=is%3Apr+author%3Ahasufell+is%3Aclosed
• https://github.com/commercialhaskell/pantry/pulls?q=is%3Apr+is%3Aclosed+author%3Ahasufell

@mpilgrem (the current active stack maintainer) and me are in frequent communication. So again: I'm not sure where your concerns stem from.

---

If you want hard guarantees about how ghcup does distribution, I'm afraid I won't give them. But I think I've clearly demonstrated that ghcup maintainers collaborate successfully with all tools and projects that ghcup supports.

[tomjaguarpaw]

Right, there is currently general agreement about what working well means. As long as that continues I foresee no problems, as I said. I reserve the right to change my mind if general agreement (hypothetically) no longer holds. I don't see any particular reason it will change, I'm just saying it's within the realm of possibility.

It seems to me it's you that was concerned about "what I'm trying to get at, imply, or suggest". I hope I have clarified, but if not please ask and I will clarify further to the best of my ability.

[hasufell]

Sure. GHCup strives to be a good distribution channel. I'm not a novice in that domain and have over a decade of experience there, including major linux distributions.

Given some of my negative experiences I had (which you know about very well), I also want to make clear that I won't let any committee impose how GHCup executes its distribution or what features it has to provide. GHCup serves the community and strives to maintain trust with the community and the tool maintainers (including stack).

So your concerns are absolutely valid, but the discussion about specific distribution policies here is misplaced imo, because it's ultimately a question of trust.

[tomjaguarpaw]

In my personal and professional life I have been a very satisfied user of GHCup for many years. I know it to be well-maintained and reliable and I am grateful to you for this contribution to the Haskell community. I have never used Stack. Nonetheless, in my position as Haskell.org committee member I have a responsibility to represent the interests of a wide variety of different groups, Stack users and leadership amongst them.

The trust-building efforts you have made with the Stack maintainership are very welcome. On that basis, and the basis of everything discussed here, I am happy to recommend to the committee that GHCup become the sole install tool mentioned on www.haskell.org.

I believe, then, the only remaining component is for Stack to be treated the same as Cabal, with regard to when they are installed by default. Please let me know when that work is completed.

[hasufell]

Nonetheless, in my position as Haskell.org committee member I have a responsibility to represent the interests of a wide variety of different groups, Stack users and leadership amongst them.

Haskell.org committee only represents Haskell.org, not any users. It is not voted by the users.

As GHCup maintainer I don't represent anyone, but my actions have consequences on more than half of the community, can break Github CI (and even block githubs weekly virtual images creation process... and I have occasional communication with Github staff due to that), break private production CIs, cause miscompilations (when switching or fixing already installed bindists), break HLS, break vscode-haskell, break mirrors in China, etc.

So my main concern are the users, not whether GHCup is featured on the download page.

While I appreciate your very valid concerns, I believe I have sufficient overview of the impact of my actions, including the relationship with stack maintainers and I prefer to handle any upcoming issues with them myself, without any "help" from a third party. My experience tells me that is the right way.

But I do believe you definitely should source opinion from current stack maintainer about what installation method they consider primary and what their opinion on the download page is. I don't know their opinion.

---

As a more general remark:

While GHCup is hosted on haskell.org and greatly relies on its infrastructure (which I'm very grateful for), I also want to make clear that it is not maintained by haskell.org.

In the long run, I hope that I won't be the only one maintaining this, but that more community members will step up. My health is not good these days and my reaction time has slowed down. I don't have the capacity to work on larger features anymore either, for now.

I believe, then, the only remaining component is for Stack to be treated the same as Cabal, with regard to when they are installed by default. Please let me know when that work is completed.

• https://discourse.haskell.org/t/ann-stack-2-9-1/5078/9
• https://gitlab.haskell.org/haskell/ghcup-hs/-/merge_requests/285

[hasufell]

@mpilgrem

Possible impact/complications of recommending stack installation via GHCup:

1. using stack upgrade is not recommended when using GHCup, because stack replaces the current binary unconditionally, which does not work well with GHCup (e.g. it may replace stack-2.7.5 with something newer). There's a post-install message explaining to use ghcup install stack latest instead.
2. since we now support and install the new GHC installation hook by default for stack that means a large number of users will install GHC through this hook. This will cause bug reports. Since hooks are supported by stack, that's to be expected. I'm watching the stack issue tracker anyway and will be able to give support, when necessary.
3. As you're aware, GHCup provides some additional stack binaries like Darwin aarch64, which are not "official".