Upgrade template

[lsmor]

Description

Provide a modern haskell setup with language server included. Also updates CI using haskell-ci which creates a CI pipeline from the cabal file. Also, it is different from PR #3 because it uses the recomended version of ghcup.

in PR #3,ghc version is set to 9.0.2 I'd recommend against this since ghc-8.10.7 is the last recommended version of ghcup (as specify here).

I am not sure how the docker file shoud install ghc. In this PR, ghcup install ghc is used. It will install the latest recomended version (currently 8.10.7), but this changes over time which can cause a conflict with stack. This is due to the fact that stack most know in advance the compiler version to use (vi stackage snapshot).

To summarize. We have two three options for installing ghc:

• ghcup install ghc will keep ghc instalation updated and inlined with the language server, but will conflict with stack snapshots when the default version of ghc is changed within the ghcup tool
• ghcup install ghc <latest-version>. This allows to have a fix version of ghc that wont conflict with stack but at the risk of having a template that gets outdated as ghc development moves on
• Don't depend on stack. Directly use cabal for project building... I know stack is the prefered tool for beginner (and not so beginners), but it is more usefull when it comes to share a project with reproducible builds. I don't know if there are any benefits of using it here in the template.

I am trying to figure out a way to do stack init and automatically choose the best snapshot to work with, based on the system ghc installed.

Related Issue(s)

This pull rrequest solve #1.

[sagor999]

@lsmor I will convert this review into draft. Once it is ready for review, feel free to mark it as such and I can review it. Thank you!

[lsmor]

@sagor999 . I've been playing around to have a template which doesn't deprecate when ghcup decides to move from ghc-8.10.7 to ghc-9.x.x. There are two options here:

• We can fix the version of every thing in .cabal and stack.yaml, and manually update the compiler version, the base library version and the stackage snapshot version when necessary.
  • The good: That wouldn't be so complicated and can be documented properly.
  • The bad: Active mantainance would be requiered, but all depends on which speed ghcup moves from one version to another (not that often AFAIK).
• We can construct the .cabal and stack.yaml on the fly when building the container. This can be done by checking which version of the compiler has been installed by ghcup and then cabal init and stack init will automatically choose the right version of packages and resolvers.
  • The good: Any update of the compiler won't need change on this side. So the template will be update with very little mantainance effort
  • The bad: cabal init will create a much simpler project: pretty much a simple executable project with no tests nor benchmarks. The resulting template is enough to experiment with haskell nevertheless

It is up to gitpod what to use. I don't know which solution is better for you

[sagor999]

Hey @lsmor
Thank you for spending the time to figure out different ways to solve this.
I think it would be best to try to go with second approach: We can construct the .cabal and stack.yaml on the fly when building the container.
That will reduce ongoing maintenance and a chance for this template to get broken, and yet still provides a way to try out haskell using gitpod.
What do you think?

[lsmor]

@sagor999. Yes, I think it is the best approach. By default you get a minimal working enviroment, users can provided their own cabal / stack file if they want. I can provide some instruction about how to do this, since I am building a more complex project using gitpod.

[sagor999]

@lsmor would you be able to provide a PR that implements that by any chance?
I am not very familiar with haskell myself.

[lsmor]

@sagor999 Yes of course!!, i'll convert this draft into a PR once I got everything done. I've already pushed some commits in the direction we've decided, but haven't tested yet. Will let you know ;)

[lsmor]

Many changes have been done. Let me explain each:

• .github/workflows has change to include autogenerated CI file. This is done with haskell-ci which generates a ci configuration from the cabal file. Same with .travis.yaml
• Dockefile has change because it is the purpose of this PR
• .gitpod.yaml has changed to build with stack. This prevents some issues with the language server, that would be solved with more configuration if built with cabal
• CHANGELOG.md has change to introduce the changes.
• GitpodTemplate.cabal does not follow regular haskell naming convention for cabal files (lower kebab case). New cabal file is gitpod-template.cabal
• README.md include instructions if you want to integrate your own project with gitpod
• Benchmarks are removed, and file names for src and test has change. This is a consquence of writing the cabal file on the fly as discussed in previous comments in this thread. When creating the cabal file from comand line, we loose flexibility.

[sagor999]

@lsmor thank you for PR!!! 🚀 🧡