Update install instructions on landing page

[BinderDavid]

Fixes #37

Haskell platform is officially deprecated, and using ghcup to install cabal and ghc is strongly recommended for beginners.

[BinderDavid]

For some reason I got confused between 34 an 37 ☹️ I meant to fix issue #37 but named the branch fix-34...

[andreasabel]

Thanks!

[ulysses4ever]

I'm not against this change (and I'm certainly pro cleaning up cruft like mentions of Haskell Platform), but I'd like to point out that I'd expect haskell.org/cabal to roughly follow haskell.org/ghc and be a place to distribute binaries and not teach newcomers how to setup the "Haskell Toolchain" (the /ghc section also never mentions ghcup!). The latter is the job of haskell.org/get-started, which is prominently featured on the index page of haskell.org. I invite you to reflect for a moment on the fact that all these pages live under one domain and arguably should strive for some consistency in terms of what level of abstraction they employ.

[ulysses4ever]

And it's not only a question of consistency, but also of following DRY: I really wish to avoid gazillion independent tutorials preaching ghcup, a tool with a sole maintainer, that can cease to exist at the next cycle of technology innovations. Much better imo would be to reference a single source of truth (e.g. haskell.org or the Cabal user manual), which has a better chance to be updated in a timely manner if the technology shifts.

The way I did it in cabal's README is I referenced haskell.org/ghcup which is not as future proof but haskell.org/get-started didn't exist at the time, I think.

[ulysses4ever]

There's a fresh PR against the cabal repo that updates the manual's "getting started" section with a reference to ghcup: haskell/cabal#9212 Exactly what I hoped to avoid. I'd lean towards having it in the manual only, and the website would only reference the "getting started" of the manual rather than giving specific instructions.

[BinderDavid]

Note that I didn't introduce the reference to GHCup here, it was already there before, but it linked to an older repo of GHCup instead of to the current website. And apart from removing the reference to the Haskell Platform, I only updated the upgrading instructions: If the user has installed his version of cabal with GHCup, then he has the GHCup install directory already in his $PATH, so upgrading via GHCup is then the operation which is more likely to succeed than installing cabal via Hackage (due to the $PATH shenanigans again).

[ulysses4ever]

I didn't introduce the reference to GHCup here, it was already there before

Oh, I missed that. Good with me then.

[tomjaguarpaw]

Is this waiting for anything to move it forwards? @andreasabel or @ulysses4ever?

[ulysses4ever]

@BinderDavid would it be possible to preserve hard wrapping of the text?

[BinderDavid]

I have pushed f0770c9 which breaks up some overly long lines.

[ulysses4ever]

@tomjaguarpaw thank you for the ping!

I'm fine with the current change. I don't have permissions to merge though.

@Mikolaj if you want to give me write permissions, I can help with this kind of contributions.

[tomjaguarpaw]

I think there's also still a manual step involved for deployment. Maybe the cabal folks would like to incorporate this website into https://github.com/haskell-infra/www.haskell.org/ so it can use our automated deployment technology.

[ulysses4ever]

@tomjaguarpaw this sounds exciting! Is there a description of what exactly we need to do to get there? Maybe a link to a previous migration to auto-deployment for some other sub-site?

[tomjaguarpaw]

I think you can make a PR that just copies over the contents of this repo into the www.haskell.org repo and then make the tweaks necessary (if any) to persuade Hakyll to include those static files into the artifacts it generates.

[Mikolaj]

@Mikolaj if you want to give me write permissions, I can help with this kind of contributions.

Oh, yes, please! I bumped you minimally, from Write to Maintain. Is that enough now?

[ulysses4ever]

Oh wow, I did have Write permissions after all... All right!

@BinderDavid I'm happy to merge but I'd prefer you fixing the wrapping I mentioned in the comment.

[Mikolaj]

I didn't introduce the reference to GHCup here, it was already there before

It might have been me, thinking about wiping out cabal-website altogether, but temporarily just adding ghcup to the Haskell Platform that was already there. I totally agree with DRY in this case and automated deployment would be amazing.

[ulysses4ever]

@tomjaguarpaw let me see if I understand the process: if we become a part of the main haskell.org repo, than for every update in this repo, we'll have to open a PR against haskell.org, and when it's merged by someone with write permissions on the haskell.org repo, it will be automatically deployed?

Who has write permissions to haskell.org? (is there a list?) Does Mikolaj have those?

Right now the extra PR bit feels a little annoying. But I don't know how annoying the current process is, so I can't judge.

I thought that an extra PR may not be necessary if we use the git submodules mechanism. In that case, we only need someone to push the Run Workflow button on the haskell.org repo...

[tomjaguarpaw]

if we become a part of the main haskell.org repo, than for every update in this repo, we'll have to open a PR against haskell.org, and when it's merged by someone with write permissions on the haskell.org repo, it will be automatically deployed?

Yes, that's right.

Who has write permissions to haskell.org? (is there a list?)

It's the haskell.org committee members. The current policy is that two committee members must approve each MR.

Does Mikolaj have those?

No, but if we go down this route I suggest we amend the policy so that changes to the the cabal subsite require authorization from the cabal team rather than the haskell.org committee.

In that case, we only need someone to push the Run Workflow button on the haskell.org repo...

I wouldn't recommend that, but an alternative is to just copy the same automated deployment mechanism we have and avoid any merging of repositories. Personally I think it's a good idea to merge repositories though. It doesn't seem like a good idea to have several different organizations responsible for different subsites in the long term.

[ulysses4ever]

@tomjaguarpaw thank you for the detailed response. This is a bigger change than what I initially imagined. I think this should be discussed on one of the upcoming Cabal meetings. Would be good to add it to the agenda, @Kleidukos. Unfortunately, I'm still not able to join those because of a scheduling conflict.