"Owners" needed for the "alternative installation options" #170
Comments
|
It may also be useful to bear in mind a ranking of most popular Linux distributions, such as the ranking from DistroWatch. |
|
We discussed this during the Haskell.org meeting and we would prefer to significantly shorten the alternative installation options, or remove it entirely. |
|
OK, so if anyone has any strong feelings about continuing to present "alternative installation options" please speak up, especially if you can help us support them with your expertise! I will also circulate this on Haskell Discourse at some point to widen the debate. |
|
Posted to |
|
Just keep |
|
CC @Mistuke for Chocolatey. I of course like Nix too. I am thinking it would be better to condense this section then cull it. I don't like the trend of languages making their own With the upcoming work on the GHCJS and Asterius upstreaming, and recent developments like https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 I think the following will be true:
So while I am very sympathetic with the idea of cleaning up this page, and in particular don't dispute these truths:
I think culling the alternatives right now would be skating to the where the puck is currently, not skating to where the puck is going. |
That's OK, once the puck has demonstrably gone somewhere we can skate there after it!. I don't think this puck moves especially quickly! |
|
Regarding nix, what we have at the moment is
That's unlikely to go out of date, but not very helpful either. Nix folk presumably already know how to get Haskell. On the other hand we have a lot of Nix expertise in the Haskell community, so maybe someone will step up to write and maintain a Nix alternative installation option. |
I maintain nixkell a small haskell-nix installer/skeleton. I'm not saying it should go on haskell.org but I agree that a Nix installation should be there given the sizeable intersection of the two communities. Also whatever ends up on there should be better than what is currently there, which I agree is not helpful at all. |
The way I see it is, if there is sizeable support for a particular option then someone will step up to be an official owner of it. I hope someone will do so for a nix installation method. @pwm, if enough people like your nixkell, then perhaps that could be it! I'm happy to hear about other alternatives. |
What does recommending Nix on the Haskell website accomplish? I am a very active Nix and NixOS user myself, and I still don't think a note about Nix on the Haskell downloads page would be useful. When somebody comes to the downloads page, I see two cases: either they already use Nix, or they don't. If somebody already uses Nix, they don't need a note on the downloads page. They might need (better) documentation about how to use Nix for Haskell—but that's something that needs to live in the Nix world. From our point of view, it isn't even clear where to link! (The Nix/Nixpkgs manual? The Nixpkgs Haskell documentation? Haskell.nix? The Nix wiki?) If somebody isn't using Nix yet, we don't want to recommend it just to get Haskell. The downloads page is primarily useful for beginners, so picking Nix up just to install Haskell would be taking on two steep learning curves simultaneously! Grappling with Nix when you just want to do some Haskell—you don't care about learning Nix for its own sake— could easily turn a beginner off Nix or even off Haskell. So what does that leave us? What's the profile of a visitor to haskell.org for whom a note about Nix would be useful? For what it's worth, I also think this is true for most specific distro documentation. Arch/Gentoo/SUSE/etc1 users don't need distro-specific installation instructions; they'll either use non-distro-specific tools or rely on their own tools and documentation. I see a reasonable case for instructions on Ubuntu or Homebrew because those are de facto default tools that beginners use without much specific knowledge or experience, but Nix today is pretty much the opposite of that. Footnotes
|
|
f-a on Discourse points out that Nix is used as much as ghcup according to the Haskell Survey. |
|
Yeah I agree @TikhonJelvis that haskell.org boosting Nix isn't important. It's more like I feel haskell.org is implicitly saying "don't trust your system package manager" that irks me. Traditional distros being terrible leading to every language developing its own branded "*up" tool is an easily understood state of affairs. That's why I would prefer a more general vague wording that just admits there are alternatives, warns in some cases they will give you out of date stuff, but also says in other cases they won't mand might come with their own benefits. I just want to start to descalate the disto vs language cold war, and keep door open to a better future. |
Could you be more concrete about some wording you would like to see? |
|
@Ericson2314 I think you have valid points, however, I also think the end-user experience should take precedence - IMHO this page should focus on what provides the best onboarding experience. It can certainly link to other pages with vague recommendations for alternatives, but to do so on this page directly detracts from the page providing clear and actionable recommendations for onboarding users. One great benefit to these changes is that it also keeps the recommendations well-maintained, which reduces support costs fielding questions and such.
While I understand that this is the way it is now, I think the end-user experience needs to be more important than that. |
|
Once you remove alternative installation options, the page no longer describes the installation of the haskell toolchain, nor is it really a download section. Having the big four (GHC, cabal-install, HLS and stack) at the top is confusing. It makes more sense to headline the whole page with a link to GHCup, and then suggest to follow the provided links if you want to install the toolchain manually. Add in a comment that stack is an alternative toolchain installation option to GHCup in the stack section, and it flows well. This order would help clarify the actual 'Installation Instructions' 1. 2. list which is confusing as it stands. GHCup installs stack if you want but it is not listed as such. And then the instructions could be easily interpreted as having to complete both steps in order to install the whole toolchain - it needs at least an or. |
I'm not sure what you mean here. Do you mean it should continue to list the alternative installation options? Could you elaborate on the rationale? The other issues are worth discussing but off-topic for this issue, I think. I would welcome you opening another ticket to discuss them. |
|
While I think this is a different issue entirely, +1 on renaming the downloads page to "install haskell", "get started", or similar. |
|
I am in favour of removing the alternative installation instructions. Once they are removed, the page has a more "getting started" or "install" feel to it. There are no downloads on the page at all, and the word 'download' doesn't seem the right label for the section. Given the brevity, once the alternatives are removed, I don't think you could say that it describes the Haskell toolchain and its installation. The GHCup site and the individual toolkit sites of the big 4 all do a great job of that already.
Sure thing. |
|
(I'm commenting here from the thread on Discourse.) (And just FYI/in case you're overlooking something.) The haskell.org/downloads page includes Official bindists, which points to the GHC downloads page. I'm bemused by the comment
I'm not a power user. The 'installation process' is to download a |
|
What about something like this format, not necessarily the wording: Recommended: Get started easily with ghcup Advanced: See [Get started using stack] or [system package manager installation options] |
To clarify before I say more , I'm speaking of using Nix for providing the ghc/cabal/hls toolchain below and not a nixified Haskell project like nixkell mentioned above. I think the small but perhaps growing number of new to nix/nixos and new to Haskell users could use a pointer to "install with nix like ...". Then sometimes users exhaust available options, run into bugs with all options, and leave out of frustration. Perhaps nix could be a failsafe for the case of providing a working toolchain. For example in the past my coworkers have had something break on Ubuntu and installing that software with Nix let them reinstall a working version rather than wait for some hotfix or update. So perhaps a "nothing else working, try using Nix" would be useful. I imagine most users that encounter problems won't seek support no matter how easy it is, but they may try another option. |
Right, but that message for those users should include/link to specific instructions, and then someone should be responsible for making sure those instructions/that link is maintained/remains functional. |
|
I didn't realise how popular nix is becoming: https://taylor.fausak.me/2021/11/16/haskell-survey-results/#s2q1 If a third of existing Haskell users use nix then this would flow on to new users adopting it, and further jsutify adding it to the page. |
|
The problem with Nix is that there are always umpteen different ways to do things, and none of them are considered standard. You can add ghc to systemPackages, use cabal2nix, or stack2nix or haskell.nix, with or without flakes, maybe ghcWithPackages. Using I think dealing with all of that should be left to Nix documentation (or more realistically at this stage, someone's blog). A getting started guide for a language really ought to provide a single blessed path that beginners are expected to follow for uniformity. And I think that should be ghcup for access to ghc and ghci when learning the absolute basics, plus stack for an introduction to projects and dependencies. People who want to do something different will figure it out. |
Well said! 💯 |
|
As a nixpkgs haskellPackages maintainer I would like to chime in here (acknowledging that I am partially repeating others):
|
|
Thanks @maralorn! In which case can you provide a PR changing the following Nix section to whatever you think is appropriate? www.haskell.org/site/downloads.markdown Line 176 in 456cc33 And can you add a "Markdown comment" next to it like [](This installation method is owned by @maralorn) |
FeedbackFeedback from circulating this to various Haskell fora. On Reddit in particularly there was very strong support for simplifying by removing references to anything except ghcup and Stack. It was pointed out that Nix has usage similar to ghcup, however, even Nix users admitted that it is not appropriate for beginners There was a lot of support for keeping around at least some reference to installation through operating system package managers even though the packages are not always up to date. The support for operating system package managers was very strong on haskell-cafe and somewhat strong on Discourse, yet nearly completely absent on Reddit. We shouldn't advertise Arch because its insistence on dynamic linking leads to very broken workflows. |
|
I can appreciate the argument that system package managers should be preferred where possible, but I would only ever use them to install ghcup or stack. I'm confused about why one would want to use them to manage ghc directly, when you can only have one installed at a time, and it's likely out of date. Solutions like |
|
Closed via #194 |
Nix to simply bootstrap ghc, cabal, and hls is a good idea from a learning curve perspective especially if the new Haskeller is a novice Nix user. Nix to manage Haskell projects for a beginner though is definitely bad for reducing learning curve. I might be preaching to the choir and you'll probably mention this in your instructions, but wanted to make this distinction so others know it's a simple option to use Nix. |
It would be great to have "owners" for each of the "alternative installation options" (listed below). That is, for each alternative installation option there should be someone who is responsible for making sure that installation option is specified clearly, works, and is kept up to date. If we can't find an owner for an installation option then I suggest we remove that installation option because (a) lack of owner probably implies the option is not very popular anyway and (b) the information is likely to get outdated and broken, causing more harm than good.
If anyone has any thoughts then please comment here. Unless the discussion here suggests otherwise, after a week or two I'll add tickets for each installation option, to find an owner or remove the option. Once we have those tickets we can post widely on the usual Haskell channels to find volunteer owners.
Current alternative installation options
The text was updated successfully, but these errors were encountered: