I demanded GHC devs to make that distinction, but this was rejected: Advertise "latest" vs "recommended" GHC versions (#19901) · Issues · Glasgow Haskell Compiler / GHC · GitLab
1 Like
GHCUp is already the reality, if you want a new user to have HLS installed, and has been battle-tested for a good while now. Any contention is solely due to poor form in the past, how we arrived at the current reality, and better dealt with separately.
If you reread the thread and the various issues lists, there has not been a single argument against it, other than let’s not scare the horses. Before we privilege community politics above the new user experience, let’s make sure the horses are even still in the paddock.
These dice were thrown long ago, and the risk event has already happened - alienation and fracturing of the community has been long-lasting and obvious.
I see an opportunity to just rip off the bandaid and enjoy delivering a single onboarding experience to the world. There are fences to be mended either way.
There’s a book on this topic: Haskell (almost)… by Alejandro Serrano Mena [PDF/iPad/Kindle]
Maybe the author will be willing to make it freely available for a price, and maybe this is something the Haskell foundation could consider funding.
Thanks to hellwolf:
As I dimly recall, there was also a lot of drama about this decision, but in the end it was also made for technical reasons…
I’ve thought about this for quite a while and I’ve come to the conclusion that it’s not going to happen (wrt the two main tooling clans).
At this point, I don’t think it makes sense to invest energy into combining forces, being particularly diplomatic or discussing the same topic over and over again.
What makes sense is to focus on solving the issues that affect users. The driving attitude of this effort should be:
- whatever tooling gets the job done first and
- whatever tooling demonstrates exceptional openness to contributions and feedback
If this is stack and haskup, so be it. If it’s cabal and nix, so be it. The Haskell Foundation can reasonably drive improvement by staying politically neutral and favoring tools that meet the 2 criteria above. If someone misinterprets this approach as politically biased, then you can’t do anything about it. It is my opinion that the Haskell Foundation will take a bigger trust hit if it stays paralyzed and inactive on topics that have emotional baggage. This is really only about formulating very clear expectations and supporting the projects that meet these expectations, whichever those are at a given moment, as well as giving all potential projects the opportunity to demonstrate their fitness to meet these goals (this is what didn’t happen during the unified installer proposal: fairness).
Open source is constantly in flux. Some projects die off in a matter of months after having been active for decades. This is normal open source evolution.
Stack was a major milestone in Haskell tooling and wiped the floor with cabal that had pretty bad UX back then. I actually doubt that cabal today would be the same if stack maintainers had kept trying to improve cabal itself. They would have burnt out long before any noticable improvement.
It’s not always collaboration that drives improvement, sometimes it’s competition.
For collaboration, I think responsiveness is key. For competition, fairness is key. HF can foster both.
6 Likes
This is certainly a gnarly problem, but I would urge the HF to not walk away from this.
At it’s creation, the HF was dedicated to broadening the adoption of Haskell, and support the Haskell tooling and infrastructure ecosystem.
The first major milestone of the HF was identification of the lack of a unified installation method as the major roadblock to Haskell adoption.
The project is listed as a proposal on the projects page:
https://haskell.foundation/projects/
Following this proposal, @hasufell and the GHCUp team went away and did the work (the work of angels) to get GHCUp up to scratch, adding stack to the tool list, solving the Windows issues and obviously striving to be the unified installer that the HF envisaged.
On establishment of these capabilities, a PR to simplify the installation section of www.haskell.org was opened.
In this PR, @chris, who is a HF Board member and the project leader of the HF unified installer project, commented:
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
stackandghcupshould both be offered as methods of installing Haskell development environments on the dowload page.
This represents and remains the status quo, and what is being called into question.
This is a HF Board member and the project lead for the unification project declaring in a lone PR that it unification cannot happen and announcing that stack and ghcup must be treated equally, without any further commentary or discussion. Has there been any further communication from the HF about failure of the unification project?
Has it failed? I use GHCUp after years of stack-only usage and rate it a marvellous success. It unifies us. It wants to get better and compete with new and emergent tools. It has demonstrated due care and attention towards stack usage. I want new users to enjoy this success and for the Haskell community to celebrate this win.
This is why, within this context, I contend that it is a mistake for the HF to walk away from this issue because, well, politics. The evidence suggests that, in fact, the activities of the HF has been prime causal in creating this gnarly milieu within which we are now stuck. Avoiding contention creates an impregnable defence against progress when the contentious bits are coming, in large part, from within your own tent.
Politics be damned, support GHCUp now, based on technical merit.
7 Likes
I agree with pretty much everything Tony has said here – ghcup has really proved itself as a universal tool with very wide adoption across the whole community and, in my view, that should be reflected in the download page.
At the time that I wrote the above this wasn’t really true, or sufficiently true – at least as I saw it. Sometimes it is worth waiting a while rather than forcing things. (The reason we have ended up where we have, in my view, is because various parties in the past have tried to force things too quickly in the community.)
I will certainly do what I can to support @david-christiansen in getting things moved along.
7 Likes
Thanks for the support, Chris. I certainly still agree with much of your commentary, especially that GHCUp might not be an ideal way to install stack for a stack-based workflow, especially if HLS isn’t important (or out-of-order).
I’m sorry if I gave the impression that I don’t think this problem (a confusing downloads page on haskell.org) is worth solving, because I absolutely do think that it is. On the other hand, I remain unconvinced that the proposed working group is the best way to get to a solution, because I think it carries a substantial risk of falling apart in a way that gets in the way of our ability to do other important things, and that this risk is not commensurate to the reward if successful. This assessment is based in part on what happened the last time around.
Why do you think that this particular suggestion is the best way to go, @tonyday567? Or does our miscommunication run deeper? My goal here is not to “win” a debate - I really want to make the best possible decisions, and there very well could be changes that I’m not aware of!
1 Like
Let me try another suggestion then. I suggest we have an initial one hour meeting to bring together people who are interested in tackling the “one download tool problem”. The meeting should be for the purpose of sharing perspectives and widening the of understanding of each participant, with regard to difficulties we might face in tackling it. It should not be for the purpose of taking action!
If it turns out that attendees at that meeting do not cover a broad enough range of community perspectives then it may well be that there is no follow up that can be made, at least for now. But we will all come out a little wiser.
Alternatively we can continue to discuss asynchronously here or elsewhere.
The GHC hook PR was merged: https://github.com/commercialhaskell/stack/pull/5585
This means that ghcup has a path to integrate better with stack. This will also fix a lot of issues users have with stack+HLS and ABI incompatibilities . It also means ghcup will by default install both stack and cabal.
The progress is tracked here: Finalize stack integration (#392) · Issues · Haskell / ghcup-hs · GitLab
10 Likes
This is great news, @hasufell!
Out of curiosity, what will this mean for users of Stack, ghcup, and HLS? Will they have an extra configuration step to get Stack to use ghcup install a GHC that’s ABI-compatible with the HLS on their path, or will that be taken care of in some other way?
I would add, there is current demand for the release for a new version of Stack (https://github.com/commercialhaskell/stack/issues/5733), which would include this ‘hooks’ and other enhancements.
I have never done a release myself, and find the guide (Releases - The Haskell Tool Stack) (comprehensive, but not necessarily fully up to date), daunting. I am also only a Windows user, worried that I might accidently break something for Linux users.
Stack’s release guide says ‘Ensure CI matrices in docs (travis-complex, appveyor, azure) have current stackage snapshots and GHC versions’, I and Sibi Prabakaran have been trying to move Stack to GHC 9.0.2 or GHC 9.2.3 - the latter overtaking the former. The sticking point is two macOS-specific bugs in process, one fixed but not yet released on Hackage (https://github.com/haskell/process/pull/250) and one identified but not yet diagnosed (https://github.com/haskell/process/issues/251). The latter has the kind attention of @bgamari, but if any other macOS experts out there could help pin down what is the cause, I am sure that would be appreciated. As Stack aims to support fully Linux, macOS and Windows (Contributors guide - The Haskell Tool Stack), it seems reasonable to hold off a release until the macOS things are sorted and published.
1 Like
On GHC ABI (application binary interface), my understanding of the problem is this:
For some Linux users (Debian 9, Fedora 27), the version of GHC 9.0.2 linked on GHC’s download web page is broken. However, elsewhere, ‘9.0.2a’. versions are now available for ghc-9.0.2a-i386-deb9-linux.tar.xz, and ghc-9.0.2a-x86_64-fedora27-linux.tar.xz.
Very recently, Stack’s download of GHC 9.0.2 for linux64-tinfo6 has changed to reference the 9.0.2a version. If Stack has already installed GHC 9.0.2, a user will need to delete GHC 9.0.2 from the stack path --programs directory, to cause Stack to reinstall the GHC 9.0.2a version.
Stack should be able to distinguish things to be built using the GHC 9.0.2a version from things built, and cached, using the GHC 9.0.2 version.
That won’t fix all possible issues though.
HLS itself is built for 10 or so platforms. GHCup is used to build it, which means HLS ends up having the exact same ABI of the bindist that GHCup picks. Additionally, GHCup is used to pick the corresponding HLS bindist for installation.
GHCup and stack have slightly different strategies on how to pick a bindist. They often end up the same, but it’s not guaranteed. GHCup also ships some unofficial bindists and seems to have a larger set (e.g. stack doesn’t install centos bindists for modern versions of GHC).
One alternative would be to build more permutations of HLS bindist releases for a single GHC version and then make hls-wrapper ABI aware, but that’s a lot of work. Discussed here: https://github.com/haskell/haskell-language-server/issues/2865
But I think these issues might not be as common as the 9.0.2 debacle.
I think for the first version it would be:
- document example hooks on ghcup homepage
- have the bootstrap script (not ghcup itself) ask the user if they want to re-use ghcup GHCs for stack and place a hook for them (default would be no to keep the “true stack way”)
Then we’ll need to gather user feedback about this feature.
Thanks for the explanation!
To make sure I’m understanding you right, is the bootstrap script what’s found at https://get-ghcup.haskell.org? Is there any mechanism to ask the question when users upgrade existing ghcup installs? What about users who answer “no” but then later want an easy way to change their answer to “yes”?
Yes, this script can be found in the repo:
- Unix: scripts/bootstrap/bootstrap-haskell · master · Haskell / ghcup-hs · GitLab
- Windows: scripts/bootstrap/bootstrap-haskell.ps1 · master · Haskell / ghcup-hs · GitLab
Not for the normal cli interface, which is non-interactive and will always be.
The TUI however could theoretically achieve that. I haven’t had time to improve it. The last plan was to migrate away from brick to support windows (I made a prototype during zurihac: TUI on windows? (#198) · Issues · Haskell / ghcup-hs · GitLab ). It would probably need a lot of work.
The bootstrap script is idempotent. You can just rerun it any time.
I guess for now the ghcup documentation will have to do.
I thought about adding a command ghcup stack hook install, because at some point, cabal should also get installation hooks: https://github.com/haskell/cabal/issues/7394
That might be a reason to provide a less ad-hoc way to install hooks. But I think this is still in flux and needs further thought.
The discussion under this topic has become wide-ranging, but apologies if this is off-topic. What are the barriers to: [1] GHC/Stack and [2] HLS/GHCup being better coordinated when it comes to referring to the same binary distributions of GHC versions? I say ‘GHC/Stack’ here because Stack says it mirrors GHC’s Index of /ghc/ (and has done so for a while). For people who do not know, by default (it is fully configurable by the user), Stack looks to this YAML file to know where to look for a GHC version (and other tools), organised by ‘operating system’, ‘architecture’ and (optional) ‘variant’.
(For example, taking GHC 8.10.7 as an example, Stack’s default YAML provides sources for linux32, linux32-musl, linux64, linux64-nopie, linux64-musl, linux64-tinfo6, macosx, macosx-aarch64, windows64-integersimple, windows64, freebsd32, freebsd32-ino64, freebsd64, freebsd64-ino64, freebsd-aarch64-ino64, linux-armv7, and linux-aarch64.)
Edit: The reason I ask is to see if there is anything that could be done by me (or somebody like me) at the Stack end to help.
3 Likes
Stack has a different logic. It looks at system libraries (tinfo and libc) to pick the bindist.
GHCup does not. It picks based on distro and distro version: https://github.com/haskell/ghcup-metadata/blob/master/ghcup-0.0.7.yaml#L1807
One difference here is that it picks centos bindist for centos. Stack does not from what I see. There may be many other differences.
1 Like