Simplify download page further #93
Conversation
1fdab42 to
3c7c98d
Compare
There was a problem hiding this comment.
One editing nitpick aside, I think this is a reasonable change. That said, since changes to the download page can be a bit contentious within the community, I'd like to get input from some other folks on the committee, and ensure that we have time for community feedback before we merge.
| - [Configure Chocolatey](https://chocolatey.org/install) on your machine | ||
| - At an elevated command prompt, run `choco install haskell-dev`, followed by `refreshenv`. | ||
| 2. To install stack, follow the instructions [here](https://docs.haskellstack.org/en/stable/install_and_upgrade/#windows) | ||
| Alternative methods to install toolchain components are listed [below](#ghc-install-manual). |
There was a problem hiding this comment.
Maybe we should combine this section with the next section, or rephrase this. saying "below" when it's literally the next line of text reads a little oddly to me.
I'm not sure. |
Correct me if I am wrong, but are these changes not proposed because GHCup now installs Stack and works on Windows? And is that not part of the HF unified install plan? |
Maybe. I can't comment on what HF's goals are or how the proposal will turn out. But I thought haskell.org is independent of HF? |
According to the (not yet accepted) installer guidelines proposal
The guidelines seem to be aligned with this PR and furthermore you are listed as one of the contributors to the planned work on that proposal!
It is an independent yet affiliated organisation. I would guess that Haskell.org is likely to (but not required to) drive forward work approved by HF and vice versa. In any case, I think this PR is a good change to make now that GHCup supports Stack and Windows (thanks!). |
Yeah, I've been consulted, but also been very confused about certain events and statements, so I'm not sure.
Well, if you care about aligning with HF, you might want to wait out the actual proposal. |
Fair enough. Still, I think this is a good change regardless. Now that GHCup supports Stack and Windows we should simplify the download instructions! |
|
I'd like to encourage merging this now. Ghcup's windows support is quite good at this point, and this would further help clear things up. |
|
Even if I'm not 100% convinced about the current state of the stack integration, I guess more user reports will help us understand if it's working well or not. The way is forward. |
|
Wrt windows, there have been more improvements that should make installation smoother:
Wrt stack, the current state is that we print informative post-install messages: |
|
At this point... we could debate whether we should do away with the entire downloads page and just drop the user to https://www.haskell.org/ghcup/ At the bottom of the page is a "other installation options" link, that I think could then redirect to the gitlab ghcup repo wiki, where I just created a page based on this PR: https://gitlab.haskell.org/haskell/ghcup-hs/-/wikis/Other-installation-options Of course, I'd expect closer monitoring and feedback from the haskell.org committee on changes to both the wiki and the ghcup page. But I'm putting this forward as an option. |
|
The effect of this change is to de-emphasise Chocolatey and the direct installation of Stack, and give more prominence to ghcup. I am a happy long-time user of ghcup and I know it to be a high-quality piece of software. Since ghcup now supports installing Stack and installing on Windows unifying installation instructions like this makes sense to me. However, the Haskell.org committee has a responsibility to navigate carefully around the treacherous waters of controversy. I think it would be very helpful to hear from representatives of Stack and Chocolatey stakeholders. If they are in support of this change then great, let's go ahead! |
|
@tomjaguarpaw absolutely |
|
How can we facilitate those stakeholders to give their input? |
|
Perhaps starting discussions on Discourse/Reddit/haskell-cafe would be a good way to get broad input. |
|
For my part I disagree (strongly) with the proposed change on the grounds that I would never recommend to anybody wishing to use I have absolutely no interest in reopening this discussion, but I can assure you that the stack team as a whole do not regard Maybe at a future point a meaningful process for developing widely recognised universal installers can be established — I certainly hope so — but, as I see it, those conditions have yet to be met. In the meantime I think |
That's interesting, given that it was you who requested the feature of ghcup being able to install stack. Why did I add it?
Why? |
There was a problem hiding this comment.
I'd personally hold off on removing or deprioritizing the explicit stack installation instructions until the ghcup+stack and ghcup+windows configurations have been in the wild for a while. These are very new features, and recommending them as the first means of installing tools is going to have our newest community members acting as initial testers for these features.
As I understand it, the stack+windows setup has been working smoothly for many years, while ghcup+windows is new and possibly has bugs that haven't been ironed out by real world use and a lot of users. I'm happy to see it mentioned as an option, but I do think we should stick with promoting the options that have the best track record for success here.
My suggestion is to add a line on the old ### Windows section, something like:
3. To install `ghcup` (which supports Windows as of YYYY-MM-DD), follow the instructions [here](windows install link for ghcup)
That's a valid alternative stance. My impression however was, that there's consensus that having one set of instructions across all platforms for all tools is the primary goal. And the only way to achieve that is to expose it to users and fix the bugs. If the idea is to list the most battle-tested ways of installation, then the current download page already violates this, because it doesn't mention e.g. the package manager on gentoo or other distros that correctly package GHC as the primary way to install. |
|
@hasufell said:
I made it clear throughout — and here — that a unified installer was the goal but that does not mean that we achieved it. To achieve that there would have to be a widely accepted agreement that any given installer was fit for installing a
I stepped away from the whole effort because it was too exhausting, while nobody was listening across the well-established lines of contention. My views have not changed. We need a working framework for building trust and resolving these isssues — and this issue tracker is not the place for that. I am sorry but I am not willing to reopen this discussion. The key point here is that the |
Can you explain why ghcup did not achieve that? I think this may only be obvious to you. |
As I said, I am sorry, but I am not reopening that. My point is that it should have been obvious to anybody participating in the process that it had broken down without satisfactory resolution. |
I'd much rather have highly reliable and well-tested installation paths for newcomers. These are the folks that are the least able to find support and help with things, and the least likely to be willing to push through installation hassles. Ensuring that they have a good and easy experience is IMO far more important than that there's a single way to do it.
This statement is true, but it does not follow that "we should recommend novel and relatively less tested workflows to absolute beginners." IME, beginners rarely report bugs or problems - they assume it's their fault, or they don't know where to report bugs, or they don't know how to make good bug reports. They're the worst audience to use as beta testers, if all you want is user feedback. Also IME, beginners (rightfully) see problems with recommended installation instructions as a red flag - "Well, if this is broken, then the whole enterprise is probably bad." Asking them to invest further effort in reporting their problems when (by their perception) they've already 'wasted time' trying out the recommended thing is a problem.
I do want to clarify that I don't have any reason to believe that |
I'm afraid that's not a constructive comment.
I can assure you it's not obvious. You're not speaking for the rest of the people that were involved. |
IME, many new users of ghcup seek help on IRC and they get served swiftly. The ghcup homepage has links to #haskell and #haskell-ghcup via kiwiirc. There's no need to create accounts, post issues or anything. This method has been used since a few years and it has been working well.
Fair enough. |
|
@hasufell I have outlined the key points as I see them. This discussion is now in an utterly non-constructive state, something I am keen to avoid, so I am going to stop here. |
You haven't. You've just repeated that the stack team doesn't regard ghcup as a satisfactory means to install stack, without any explanation, except that "it should have been obvious to everyone".
@parsonsmatt has raised some valid points that will help the committee make a decision I hope. So there's nothing unconstructive except for your comments. |
I'm sure you've helped a lot of people with this, and that's fantastic, but you're filtering for two things: users that didn't give up when they needed help, and users that are comfortable with IRC. That's a shrinking group of people, even among programmers. I've never figured out how to use IRC effectively, and that would be a blocker for me to seek help on something. The issue that I am concerned with isn't "% of people that ask for help and are helped" - which I'm sure you're doing great with - it's the folks that give up before getting that far. |
Sure, but that's a number we don't know about any installation method, including the stack installation script. That's why I'm not sure that just waiting will get us further if this question needs to be answered. Even including this question in the haskell survey may not get us further since people who have given up on haskell installation are unlikely to participate in said survey. |
|
I think setting a "burn-in" bugfixing period of say two months would be reasonable, in which time people could promote testing of ghcup more widely both in terms of windows and stack support. At that time, a decision should be made on the basis of data available in terms of if the single solution works well. As a general practice, I think any claim that "x does not work well, but I will not tell you why," no matter from what corner it comes, should not be a blocker. The HF, which haskell.org is affiliated to, states one of its goals, commendably, as "Transparency" and explains "All technical decisions related to HF’s open source projects are proposed and debated in public." So if there is a decision to be made on any technical matter, including in this case, it must be should be made on considerations which can be proposed and debated in public. Suggestions that there are reasons which will not be discussed or explained, but must be respected, undermine the goals of a transparent, open, collaborative software community. (Edit: People are of course free not to participate in public discussions. But they should in turn have no expectation that their non-public reasoning should then be taken into account.) |
There was a problem hiding this comment.
This is clearly a controversial change. Haskell.org should take community feedback seriously, and this means we cannot merge this as-is; we should seek consensus (ideally) or a compromise. It doesn't look like will reach that in this GitHub thread, unfortunately, so I think the PR should be closed for now.
While this is technically under the purview of the Haskell.org committee, this something we want to collaborate on with the Haskell Foundation, since really we both want to promote Haskell and make things easy for new users.
I think the suggestion by @parsonsmatt to add ghcup as a new option for Windows does make sense; but we probably want to do that in a separate PR, as it doesn't "simplify" the downloads page.
|
@gbaz right. In fact I'm going to release a bugfix release this week. It probably makes sense to let all the code changes sink in and have sort of a feature freeze for some time. But I do expect a decision to my proposal PR haskell-org/committee#8 In case it's rejected I hope to get clear reasoning if and when it should be revisited. |
Relatedly, I'd like to make it clear that, although I am a Haskell Foundation board member, in this discussion I am speaking solely in my capacity as a Haskell.org committee member. Chris Dornan is also an HF board member but I believe he is speaking solely in his capacity as representative of Slack (although I am not certain and I don't want to put words into his mouth). |
Well, I don't. See the following links for extensive documentation why I think HF is not the right place:
|
|
IMO, one clear improvement here would be to list "just install stack and let it install and manage GHC" very prominently in the alternative install methods. I wouldn't personally do it and it shouldn't be billed as a complete install option since it doesn't set up GHC, GHCi, or Cabal to be used directly; but it is a very common workflow that does work for a lot of people and isn't represented well on the current page. I'm not saying that's enough, but it's better anyway. |
@cdornan As someone who doesn't know where this discussion took place, can you provide a link or anything? Not trying to relitigate; just understand. |
@hasufell Regardless of the feelings of the stack team, I want to say that I appreciate ghcup being able to install stack. Having one install tool that can be used for everything is valuable to the Haskell community as a whole. The stack team obviously feels that more people should just use stack for everything and use their own installer so things are less klunky for that specific use case, and they are obviously free to have that opinion; but that doesn't make your work meaningless. I have used stack via ghcup in cases where I just wouldn't have bothered with figuring out how to download and run stack's installer. |
@parsonsmatt I'm starting to disagree rather strongly on this specific point. Just today I tried to add more communication channels, but they all have worse UX:
With kiwiirc, you click a link and can start chatting instantly, without registration or anything else. That's the primary goal. |
Well, I don't really know what the stack team thinks, despite Chris' claims.
There are a couple of ways forward:
|
UX is a subjective thing. I'm not making any claims about what's better or worse, just what people actually use. IRC has evidently been shrinking since 2003, despite the internet growing remarkably quickly in the same time period. |
Sure, but it's an objective advantage to be able to seek help without creating an account or typing in your phone number somewhere. |
|
We are in known-dangerous territory here, with an unfortunate history of conflict. May I peaceably suggest that we avoid words/phrases like "of course", "obvious", and "clearly"? I posit that if something is truly obvious, then it does not need to be stated at all. If something does need to be stated, then, the use of these words may make the reader feel out of the loop or less clever than they would like. For reasons I can only guess at, this page and the installation process for Haskell has evil associated with it, with the power to make conversations highly contentious very quickly. I do not suggest we simply give up in the face of this evil, but instead proceed delicately and with the full knowledge of the evil that is here. In other words, we should all strive to give others the benefit of the doubt -- and then some -- in these discussions. There are a number of closely held opinions here, and the best way, I think, to convince others of your opinion is not to force the issue, but instead to be open to hearing theirs, in the hope that they will reciprocate. |
|
@goldfirere absolutely. I've explained in the past, that I believe that the main goal should be to have one set of instructions and that these may very well be "use the stack install script", see here
My position on this hasn't really changed. Here's the important part: the download page should not be a battle-field for political parties, but be as simple as possible and give newcomers a pleasing experience. Whatever that may be at a given time. Newcomers shouldn't need to care about any of this. I've put considerable effort into supporting stack, which was requested, by, well... the Haskell Foundation. If this isn't the way forward, then that's fine and I have less features to maintain! The impression some people got that ghcup developers have somewhat of an agenda against stack, was a miscommunication within the Haskell Foundation, apparently, amongst other mismanagement issues I have raised with the HF board in great detail. It remains to be seen how you manage your board and your future projects. I hope it will improve. However, I think this is mainly an issue with haskell.org and so far I have no negative experiences with haskell.org. These are the guys who helped me set up the ghcup homepage, gave me access to github/gitlab/downloads.haskell.org, let me use their GHC CI and so on and so on. I believe it is totally valid to not merge this PR and put these efforts on hold. Despite some nonconstructive comments here, I believe we made progress:
I still think that the chocolatey side of things is under-represented (@Mistuke). Another idea I had was to actually inform users of the chocolatey install method on windows when they run the ghcup powershell script and chocolatey is detected on the system. Because, after all, it's a real package manager of sorts. |
|
I'm closing this PR for now, until we have a better picture about what the different stakeholders of the tooling landscape want. Pushing the discussion here seems to have failed, so I hope we can have better discussions in the future. |
Since ghcup now runs on pretty much any platform and supports stack, I leave this here for discussion of further download page simplification.
It should be noted that there is a minor caveat of ghcup's stack handling: of course it doesn't interact well with
stack upgrade, which overwrites binaries (no matter the name of the invoking executable). Users will be notified to use ghcup mechanism for such updates.