ghcup is not a bash script.
Well, executables downloaded from the internet.
1 Like
It absolutely is true:
6 Likes
You don’t download executables via your package manager? Or is it not the internet?
Interesting. That pull request makes many changes including removing the bindists. And removing those is neither in the title or description and I cannot find the reasoning for why the bindists were removed in the discussion. I found one comment about it only being an option for “power users”, but that should be fine to list in the alternative options next to nix which is also not for the feint of heart.
1 Like
There was a big fat thread about it right here on discourse: RFC: removing "alternative installation methods" from haskell.org (or finding them owners)
That discussion also doesn’t mention the bindists. The main argument seems to be that it is to difficult to maintain these instructions, but the old bindist and ‘from source’ installation methods didn’t seem to mention anything that could go out of date soon.
So it seems like, the community divide on tooling is not a thing of the past. It seems to be real and present. Having 2 separate competing tooling for such a niche language would look pretty messed up from outside. Not that it would matter anyway - haskell is, after all, a research language right?
I’m not aware of an alternative to ghcup that is in use.
https://taylor.fausak.me/2021/11/16/haskell-survey-results/#s2q1
Stack doesn’t provide the same functionality, nix is a fully fledged package manager, not a simple tool.
3 Likes
If someone makes a PR reinstating them I think it’s likely that would be accepted. I think the issue of bindists just fell off everyone’s radar during the discussion of that particular change.
2 Likes
Well, lots of people do seem to use stack as a comprehensive tool to install haskell and build, manage projects. Pretty sure that makes it a competing tool vs. ghcup+cabal.
I mean, according to what I’ve heard, it does seem like ghcup+stack is quite a pain to set up and get going. Still sets up for somewhat competing position.
2 Likes
I don’t think so. Many stack users use ghcup these days, especially because of HLS integration. ghcup supports stack too. There’s a (small) overlap of functionality: installing GHC. My linked PR fixes the last missing piece of integration. I think it’s fair to keep stacks own installation technique as an additional option, because it actually selects GHC bindists a little different.
So: ghcup has a much more narrow scope than stack and is not limited to cabal.
2 Likes
I would say “sometimes” out of date. The reason they are out of date is that the Haskell toolchain is not playing well together. HLS just became available for GHC 9 a few months ago. Some plugins are not even working at this moment. How should distributions update their main line GHC? I think this is a different issue, but I think it is unfair to blame the people working behind the scenes to provide the repositories for (Linux) distributions.
With respect to downloading executables from the internet. Of course, you are right, also package managers download stuff from the internet, but it is much more secure than even a non-random homepage such as “haskell.org”. Also, I trust the package manager of my distribution, a hundred percent (I have to, don’t I?).
Nevertheless, I do not want to belittle the useful work that has been put into GHCUp. It is great that we have such a tool! I just want to point out that more experienced users are probably not looking for an executable or a bash script, but for a package in the repository of their distribution. This alternative should be available, and it should not be put after a clause that is pretty much equivalent to “if you reeeally want to use your package manager, don’t count on us”.
3 Likes
I just want to point out that more experienced users are probably not looking for an executable or a bash script, but for a package in the repository of their distribution
According to the Haskell Annual Survey (that @hasufell linked above) only 14% of Haskell users use OS packages. (My hunch is that this percentage decreases with Haskell experience level.)
1 Like
No, most of the time they are out of date. That’s also why there existed unofficial PPAs.
Very few distros are able to keep up with the GHC release pace. Additionally, many distros only provide one GHC version. That simply is not enough for deving.
I’m not blaming anyone. I’m simply stating facts. I’ve worked on linux distros for over half a decade and have also packaged GHC for source distros.
This is incorrect.
GHCup releases are GPG signed and the metadata files downloading binaries are also signed:
- https://www.haskell.org/ghcup/install/#manual-install
- https://www.haskell.org/ghcup/guide/#gpg-verification
- Index of /ghcup/0.1.17.8/
- https://github.com/haskell/ghcup-metadata
This is cryptographically secure, if you use GPG correctly. Package manager basically do the same.
6 Likes
Just personally, my response would be woo hoo because it would mean that:
The stack project has worked out how to properly support hls installation. Right now, only GHCUp is the recommended way to install HLS on their installation page. Neither stack nor cabal is recommended on its own.
https://haskell-language-server.readthedocs.io/en/latest/installation.html
I would like the ability to use cabal and ghc outside of a stack context, and this proposal would mean that they are providing this.
Your hypothetical has actually happened in the past, maybe not as a single sentence proposal, but stack has been the dominant way to install Haskell for a long while now. What happened is roughly the same as what’s happening now - passive resistance and a refusal to budge on old ways and instructions.
2 Likes
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.
You meant the stack community right?
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.
This is a different question. I am proposing that GHCUp appears as a big friendly button on the splash page as an easy way of installing Haskell. I am further suggesting that ‘easy’ is best achieved by being clearly the only installation method. Neither stack nor cabal nor nix nor package managers are easy. GHCUp supports a pleasant installation of all build tools, with hls being especially problematic outside of GHCUp management. GHCUp is our only realistic option for a headline installation method suitable for modern practices.
How do we ask the stack community this question? What is the stack community - are they separate to this discourse? Is there a representative that could chime in here?
It’s hard to weigh and deal with contention if there’s no communication.
1 Like
No, that response was to @atravers’s question, not your original question. My response to your original question is at GHCUp button on www.haskell.org - #10 by tomjaguarpaw.
Seems like the same question (or the key component of the same question) to me. You said
I would like to propose to the community that http://www.haskell.org/Downloads be replaced by a link to GHCup
Well, that would necessarily deprioritise Stack, therefore your proposal can only go ahead if the Stack community agree. What they would be agreeing to is “GHCup as the Haskell.org-official way (i.e. the only way prominently mentioned on www.haskell.org) of installing Haskell” and therefore, as part of that, “GHCup as the Haskell.org-official way of installing Stack” (unless the Stack community will agree not to have Stack mentioned on www.haskell.org at all, which seems even less likely).
How do we ask the stack community this question? What is the stack community
The Stack community is the group of users and maintainers of Stack. Perhaps some of them hang out here, but I also suggest you spread your message on Reddit, haskell-cafe and Twitter, at the very least.
Is there a representative that could chime in here?
I suspect they’re not particularly interested in chiming in, since you’re proposing that they enter yet another a fractious debate to eventually be magnanimous and sacrifice their own status for the supposed greater good.
Finding ways to appeal to their own self interest is probably a more effective strategy. For example, supporting custom GHC installation hooks would reduce technical fragmentation whilst at the same time potentially appealing to their self interest: they may find it reduces their maintenance burden. Perhaps you could start with that, or some other proposal that can be easily cast as win-win.
2 Likes
What I mean is that I have to trust a third party with installing software on my computer. That is something I am not used to as a Linux user. I don’t want anybody to interfere with my setup. I understand that GhcUp only installs into the user directory (is that so?). I think this is an acceptable and the best way to go, and that is why I welcome the development of GhcUp. My point is: please don’t make native installations second class! They are already hidden behind drawers and discouraging statements. I disagree with this attitude.
EDIT: I think a good way to phrase would be: Native installations “may be outdated” and are not “officially supported” or “verified” or “validated”. Not sure what word is best to use in this context.
3 Likes