Well, I think we will not reach consense here. I have deposited my opinion, please respect it, and keep it in mind. Thank you!
Hackage packages are all installed into the .cabal or .stack directories in the user directory. I think this is a good way to go, as I stated. I believe GhcUp does the same using the .ghcup directory. This is what I was asking before.
Stack by default installs binaries into ~/.local/bin.
https://docs.haskellstack.org/en/v2.7.5/yaml_configuration/#local-bin-path
Rest assured, your opinion was shared by others and taken into account when our policy for the Downloads page was formed.
I don’t think anyone questioned that package managers are in general great.
I was merely pointing out that “random script from the internet” is a stark misrepresentation of the ghcup project and that you’re very likely using a lot of tools that download and install stuff from the internet without your package manager anyway: cabal, stack, cargo, pip, npm, …
For linux users, it’s not particularly useful to have a download page tell them about distro packages. These are not maintained by the project (most of the time) and users can just do dnf search ghc and similar. We don’t really need to duplicate introductory distro information on haskell.org. That’s what the previous download page did… and it was impossible to maintain and constantly out of date.
I also think it would be super great if the haskell site had a “big red button” for installation, linking to GHCup. I use GHCup with stack, and think it’s great. Details on manual installation could be kept available, but less prominently, for more experienced users.
My main incentive here is that I’d like more people to overcome the (low, but entirely non-trivial) activation barrier of setting up haskell+HLS, playing around with it, and joining the Haskell community. To me, that seems overwhelmingly more important than finer details of what the best installation strategy is, because it will lead to more adoption of the language, and therefore a better experience for everyone. (I sort of wish this kind of issue was a core priority of the Haskell Foundation, along with centralizing learning resources, but that’s a separate discussion)
I am simply tired of seeing new users struggle with our installation instructions, and think a big friendly ‘try haskell’ button would make a big difference. That’s the easily defined and obtainable good I see; whether this is greater or supposed is of course up for debate.
But the rest, tying in approval from stack maintainers for this to occur and having a big debate, is your construction of the problem, not mine. It’s your decision and the decision of the committees you represent that the stack team has veto power over this.
It’s a strange leap of logic that making life easier for new Haskell users by putting a GHCUp button on a page necessarily involves appealling to the self-interest of stack maintainers. I don’t know what their interests are so I would make a meal of it, personally. In general, the whole community is making a meal of it if we can’t do a big friendly button because it’s just the right thing to do (subject to technical correctness that GHCUp is a good option for this).
And what could I possible do to help a stack PR that is described above as ignored for the best part of a year with nothing further to be done? I can’t even find the stack team.
Hi. I’m an educator and I teach Functional Programming and we use Haskell as our learning base. The current setup in our labs is pre-set for the students so those using our lab machines only will not need to install anything.
For all other students, I absolutely do not recommend the downloads page as a port of call at all. I maintain an entirely separate set of installation instructions, one per platform in fact, that students can follow to complete the installation on their own computers. In each case the path involves installing ghcup and then stack, since we use stack for our projects (we have determined over time that this minimises per-platform issues and faffing with cabal files).
I am strongly in favour both of simplifying the download experience through any and every means. I do not think that there is value in considering the position of advanced users here, since they are not the audience of said page. This includes commercial haskell interests.
I also commend @hasufell’s comments about the anti-value of distro provided Haskell tool chains in general and specifically in the case of Arch Linux, whose position on Haskell packaging I have long felt to be inappropriate. Any pointers towards those installation methods on the downloads page would have to be so heavily caveated as to be worthless to a newcomer.
Would you mind sharing these publicly?
I’d rather not share them publicly because they’re not as polished as I would like (and I’ve learned of some improvements that could be made since I wrote them). But I’m happy to pass them on to you off-list, so feel free to shoot me an email at alex@dixonary.co.uk.
OK, email sent! Thanks.
It looks like there’s a "vicious cycle" at work here:
[…] I know regressions in Stack with newer GHC/Cabal versions (like overly aggressive recompilation, or broken deregister support for private libraries) causes the Stackage team pain and suffering. […]
[…] I wanted to package some Python packages that use
pypandoc, so I started adding haskell packages for packagingpandoc. IIRC this brought the first batch of 100+ haskell packages into the repositories. Then from time to time I added some other useful stuff on request, resulting in the over 600 packages now. Before the dynamic-only change it was somewhat hard to keep up with upstream already due to the very long build+upload time.
…and now this is apparently causing “pain and suffering” here and presumably elsewhere. So what’s the solution?
That seems to be the way to an even smaller Haskell community in the long term - at this rate, we really ought to start working on a Haskell Machine just in case everyone else decides to “cut us loose” (along with Haskell)…
There’s a common problem across Stack, Arch Haskell and apparently here too: not enough people in each project to keep up with its maintenance. If we instead all unite around our shared interest - Haskell - to help solve each other’s problems in addition to our own, then Haskell will have a much better chance of thriving in the midst of newer competitors like Rust, Go, Zig (or existing ones like Standard ML).
In the light of feedback, let me attempt a summary of my position and what I am proposing.
Proposal: That a button be added to www.haskell.org that says something like “try haskell” which links to GHCUp.
Technical:
The technical argument is very narrow. There is community consensus that HLS is a core part of “installing Haskell”. GHCUp is the reliable way to install HLS, and is the recommendation of the HLS team:
Direct installation from source, while possible via
cabal install haskell-language-serverandstack install --stack-yaml stack-<GHCVER>.yaml, is not recommended for most people. ~ Installation — haskell-language-server 1.7.0.0 documentation
If this technical judgement is accepted, neither cabal nor stack can be included as valid ways to “install Haskell” for new users.
This is true whether or not the GHCUp installation of stack meets the requirements of the stack team.
Social:
About 6 years ago, I recall sitting in a Haskell course being shamed and ridiculed for choosing to use stack. The instructor stopped presenting and, instead, watched over me as I uninstalled stack, hyperventilating about its shortcomings.
Events such as this are historically ubiquitous and often traumatic for everyone involved. The community has a trauma response whenever something vaguely akin to the old debates pops up, and I apologize if I haven’t handled this with enough sensitivity. There has been fault on both sides - I personally regret public comments about cabal I have made in the past - but it is canon that the stack project has been treated very shabbily.
Political:
it is currently politically untenable to treat ghcup and stack on anything other than an equal footing ~ https://github.com/haskell-infra/www.haskell.org/issues/166#issuecomment-1086726154
Technically, stack and ghcup are not on an equal footing, so the main reason progress towards a single onboarding is impeded is political.
The problem with the politics in this situation is manifold:
In this context, set up as a political tradeoff, closely-held opinion and politics will ride roughshod over any appeal to the public good. The stack team will likely see technically valid arguments to promote GHCUp as an excuse to bash stack yet again, and will veto progress, via private comms at senior levels.
Solution:
If the technicals outlined above are correct, the problem doesn’t have to be constructed this way. We can both have a big button that reliably installs a version of what is a “Haskell installation” suitable for new users, and seek to build trust and empowerment of the stack team. They are not inextricably linked and they are both the right thing to do.
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. … I suspect they’re not particularly interested in chiming in
I can do this, but I worry it will be counter-productive to have the messaging cast by a single community member with little in the way of political clout.
If stack-aligned members of the community do not trust posting on this discourse (perhaps because they are fearful of the big pile-ons that this community is reknown for) then surely this is a core problem for the Foundation.
An alternative to this individualistic approach is for the Foundation to take ownership of the reality that the stack team has not been involved in public discussions, and seek to fix this. Facilitating a transparent, safe and centralised place to work things out must be the minimum standard for the leadership role the Foundation has. I imagine the stack team has representation at Board level, at least, and I would ask the Foundation for public comment representing their point-of-view.
Regardless, the status quo solution is dysfunctional, has low probability of success, and sounds bruising and exhausting. My proposal is to stop making these same mistakes over and over again. Acknowledge and separate the necessary reparation and healing work from the technical decision to promote GHCUp as a reliable way to install Haskell for new users.
Alright, here’s a revised suggestion for www.haskell.org:
Rename “Downloads” to “Specialised Installations” so it no longer appears in the results of searches (note: the actual folder downloads/ can keep its name);
Add a “Start Using Haskell Now!” button to www.haskell.org;
The URL for “Start Using Haskell Now!” is assigned to GHCUp (for the time being).
This seems to be the “best least-worst of both worlds”:
Unlike what happened in that course, Stack isn’t being purged - it’s merely relegated to being another alternative. If some find that annoying, they can help to improve Stack (maybe even to the point of surpassing GHCUp).
Keeping downloads/ (albeit under a different label) means there’s still a place on the Haskell site for other new “development suites” (even GHCUp was new once), or revitalised existing ones e.g. a future Stack.
This is a fine proposal, and encapsulates the high points. If this issue was to gain some traction, I suggest exactly this as the starting point.
Specialised installation is a nice spot to put caveats about GHCUp as well. Cases where we know it fails, the problem areas, why you would prefer different tools like nix or stack, and any roadmaps or emergent tools that may replace it.
Some replies to particulars of Tony’s message, before I write something more substantial.
To be clear, I made this comment specifically with regard to what is mentioned on the www.haskell.org Downloads page, that is to say, it is currently politically untenable to prioritise one or the other on that page. No other meaning of “equal” was intended to be implied. Having said that, it is politically tenable to start doing the community consensus building work needed to change this status quo. It just needs someone with time, will, energy and diplomatic skills.
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. … I suspect they’re not particularly interested in chiming in
I can do this, but I worry it will be counter-productive to have the messaging cast by a single community member with little in the way of political clout.
On the contrary, I think it could be very helpful to have this messaging come from a Stack user who cannot be interpreted as having a vested interest against Stack.
If stack-aligned members of the community do not trust posting on this discourse
To be clear, I don’t think that Stack community members mistrust posting on this Discourse. I simply don’t think they have much incentive to.
Thanks Tony for writing up your thoughts in detail. To reiterate, I agree that simplifying the “Downloads” or “Get started” story on www.haskell.org is a valuable goal. The challenge is not technical. The challenge is to come up with something that has broad community consensus (that is, it is a political and diplomatic challenge).
I recently wrote about how I would tackle that challenge, and I’ll reproduce what I wrote below.
Perhaps the Haskell Foundation would be willing to convene an Onboarding Working Group to tackle this issue. If so, I would be willing to serve on it. Would you be willing too, Tony? The decision about whether to convene the group would be under the purview of Executive Director @david-christiansen.
Foster ongoing discussion in the community on the differences between stack and cabal, and stack and ghcup
The aim of the discussion would be to surface knowledge of the differences and to spread that knowledge. The technical differences are fairly well known but it’s still important to resurface them. The social differences are probably more implicit and thus more important to surface. It is important to understand why people use one tool over the other, what they value in the tool they use, and how they interact with the support networks that that tool provides (issue trackers, informal support channels on Haskell forums, etc.). The contemporary discussion on Reddit is an example of this kind of thing, but by “foster ongoing discussion” I mean try to make it a topic of interest across a wide range of community forums over a period of several weeks.
Widen the debate to discover whether there are any areas in which the differences between the tools can be reduced
This should be done with a clear understanding of the technical and social differences in mind, so must come after the step above. Examples of reducing the difference include adding Cabal support for Stackage LTS snapshots and having ghcup become an officially-supported installation method for Stack.
During this process I hope that trust will develop in the community that it is OK to have hard discussions on these topics without generating acrimony (I think this has actually happened organically over the last few years, but there’s still some more work to do).
I hope that one outcome of the process will be a community consensus regarding the different use cases of the different tools and therefore it will become clear and non-contentious how to describe the difference between the tools on www.haskell.org.
This whole process needs to be handled with delicacy, tact and empathy (although I think it’s less likely to become contentious than in years gone by).
By way of comparison, the “big buttons” of Python and Go both link to tarballs, so I think the haskell.org Downloads page is actually better than these!
onboarding working group would be great. It’s worthwhile knowing everything about our ecosystem, what we do and how we do it.
Since no-one has objected to what I’ve suggested, here’s a patch:
--- 000/Haskell Language.html
+++ 002/Haskell Language.html
@@ -25,10 +25,10 @@
</div>
<div id="haskell-menu" class="collapse navbar-collapse">
<ul class="nav navbar-nav navbar-right">
- <li><a href="./downloads/">Downloads</a></li>
<li><a href="./community/">Community</a></li>
<li><a href="./documentation/">Documentation</a></li>
<li><a href="./donations/">Donate</a></li>
+ <li><a href="./downloads/">Specialised Installations</a></li>
</ul>
</div>
</div>
@@ -45,6 +45,7 @@
<div class="branding">
<br class="hidden-xs"><img src="./img/haskell-logo.svg" class="img-responsive">
<h4 class="summary">An advanced, purely functional programming language</h4>
+ <a href="./ghcup/steps">Use it now!</a>
</div>
</div>
<div class=" span6 col-md-6">
All the Haskell site has to do is to refer to the GHCup page: it’s then up to the GHCUp devs as to what happens next. Even the Rust site has this two-step arrangement:
https://www.rust-lang.org - the main page, which refers to:
https://www.rust-lang.org/tools/install - which determines what the OS is and provides a suitable invocation of the actual rustup command.
For simplicity, "Use it now! is just a plain ol’ HTML link - the choice of its appearance e.g. as a button can be considered later…
Seems plausible, but it’s not just here that where the consensus must be built, but across the entire Haskell community. If you want to move forward with this I’d suggest posting on Reddit, Twitter and haskell-cafe as well.