Create an official devcontainer docker image with haskell-language-server

[jneira]

• It could be a great way to increase haskell adoption using it directly or via vscode support for docker images: https://code.visualstudio.com/docs/remote/containers
• It would suppose being able to use a cloud ide aware haskell environment via https://code.visualstudio.com/docs/remote/codespaces (or other provider)
• Prior work: https://github.com/vzarytovskii/haskell-dev-env based in https://github.com/hmemcpy/haskell-hie-devcontainer
• See would it increase takeup if there were a docker image with everything preinstalled? haskell-language-server#344

//cc @ndmitchell @emilypi @hmemcpy

[AlistairB]

So I think if this were to live in an official Haskell image, it would be separate from the core image that is provided. Ie. it might live under haskell:8.10.4-hls. This way the core image is not bloated for users that don't need HLS embedded in it.

The next question is should the image live in this repo and be an official Haskell image variant, or should it live in HLS repo?

Personally, I'm inclined to think it should live with HLS and be published to a separate docker image ie. haskell-langauge-server/haskell-language-server:8.10.4. (But perhaps use the official Haskell image as a base image)

The reason is that such an image is tightly coupled to HLS itself. As HLS is developed, I would imagine that would impact what goes in this image. So you might adjust HLS code and update the image in a single PR (that CI can verify).

Having said that, I know little about how HLS works 😅 I'm curious why it might be good for an HLS image to be an official Haskell image variant?

Another question, would you want to embed the HLS executable in the image? Or would you just have it auto download? If it is the former, that would further tie it to the HLS release process.

//cc @psftw

[jneira]

it might live under haskell:8.10.4-hls. This way the core image is not bloated for users that don't need HLS embedded in it.

totally agree

Having said that, I know little about how HLS works sweat_smile I'm curious why it might be good for an HLS image to be an official Haskell image variant?

Well, host the hls image could have some interesting advantages:

• we could reuse the existing infrastructure (but we dont want to add much work for existing maintainers here of course 🙂)
  • ideally some dev(s) from the haskell ide team could have some sort of permission of this repo
• it would be easily discoverable and would have the official haskell.org™ stamp
• hls and vscode haskell extension git repos already live under the haskell github org, so i think put the container here would be coherent with that
• it is the most used ide in haskell nowadays afaik

Another question, would you want to embed the HLS executable in the image? Or would you just have it auto download? If it is the former, that would further tie it to the HLS release process.

• The vscode extension downloads automatically the last available hls version suited for the ghc version of the project at hand so only the extension would be enough (and save space as we will not download all hls * ghc version matrix)
• The vscode extension could be automatically updated at container start? I hope so

[jneira]

Usually we are taking a look on what rust is doing and it seems they dont have a devcontainer in their docker official account: https://hub.docker.com/_/rust
That image is hosted directly by microsoft instead: https://github.com/microsoft/vscode-remote-try-rust
That alternative is not bad either 😄 but dont know how we could suggest ms add a vscode-remote-try-haskell here: https://github.com/microsoft?q=vscode-try&type=&language=&sort=

[jneira]

That alternative is not bad either 😄 but dont know how we could suggest ms add a vscode-remote-try-haskell here:

Maybe @Chuxel could help us with that? 🙂

[AlistairB]

it would be easily discoverable and would have the official haskell.org™ stamp

Yes, this seems like the biggest benefit to me.

The vscode extension downloads automatically the last available hls version suited for the ghc version of the project at hand so only the extension would be enough (and save space as we will not download all hls * ghc version matrix)

I think this doesn't work so well with the way the current images work. Each image tag is a specific version ie. haskell:8.10.4 and is configured to use the system ghc and not download new versions.

I think for this to work you would want an image that just installs stack / ghcup, then ghc + hls versions can be installed as needed. I guess the downside of this approach is the user needs to install new ghc versions? Or perhaps ghc doesn't need to be in the container, just the hls executable?

For https://github.com/vzarytovskii/haskell-dev-env/blob/master/.devcontainer/Dockerfile the image is hardcoded to a specific version.

Alternatively it might be easier to just have hls docker image variants for different GHC versions and the user can switch between them as they change projects.

BTW, I'm just a newbie maintainer on this repo, @psftw is the long time maintainer.

EDIT: vscode-remote-try-haskell could be cool!

[jneira]

I think for this to work you would want an image that just installs stack / ghcup, then ghc + hls versions can be installed as needed. I guess the downside of this approach is the user needs to install new ghc versions? Or perhaps ghc doesn't need to be in the container, just the hls executable?

Mmm i see, thanks for noting it.
What about to have hls over the image with the lastest ghc version full supported by hls itself (currently 8.10.5), put the hls-8.10.5 executable in PATH and let users download other ghc's on demand using ghcup? (btw ghcup could be used to download hls too but users could choose use it or the automatic download provide by the vscode extension)

[AlistairB]

What about to have hls over the image with the lastest ghc version full supported by hls itself (currently 8.10.5), put the hls-8.10.5 executable in PATH and let users download other ghc's on demand using ghcup? (btw ghcup could be used to download hls too but users could choose use it or the automatic download provide by the vscode extension)

The challenge with not baking everything you need into the container is you want to avoid re-downloading / installing additional stuff. Naively if you don't do anything, when the container shuts down it loses any changes that are not baked into the image. So you would need to reinstall other ghc versions / hls executables you had downloaded after starting the container.

The way docker solves this is with volumes that persist data between container runs, but they can be finicky. So I'm not sure if this is a good option.

I'd probably instead have something like:

• hls:8.10.4 - with a specific version of ghc + hls
• hls:latest - with only latest ghc + hls
• hls:all - with all supported ghc + hls
• some middleground? hls:recent last 3 ghc major versions?

[jneira]

Oh, yeah, i forgot containers dont persist anything by default, thanks for noting it

I'd probably instead have something like:

that sound sensible

[Chuxel]

As a FYI, someone did contribute a PR on Haskel here: microsoft/vscode-dev-containers#685

If this is good, we could merge it and it would be in the "Add Dev Container Configuration Files" UX in VS Code and Codespaces. Or if you'd prefer a different image is used, we could add that. We bundle up everything in this repository once a month (if not more often) and publish it in the products and community contributions are welcome.

There's also a "common-debian.sh" script we typically run that makes terminal a bit more user friendly since the typical production focused Docker image is intentionally thin. Any of this could be pre-built into an image. We do have a pre-built base image with this already done as well as a drop-in replacement for base debian or ubuntu. mcr.microsoft.com/vscode/devcontainers/base:buster (or stretch, focal, bionic and soon bullseye).

Generally we host images at mcr.microsoft.com if they're ones the VS Code and Codespaces teams are managing, but there's no requirement that it has to be here as long as the image comes from "official sources" rather than personal accounts.

The way these work is that a bind mount or volume is used to map in source code so it survives an image build.

[jneira]

@Chuxel many thanks for take care and your insights
I am taking a look to the pr you mentioned but i am not a docker expert, @AlistairB could you take a look to check if it is fine?

[stuartpike]

@jneira and @AlistairB the PR microsoft/vscode-dev-containers#685 I raised is based on the docker hub image '8.10.4' using tag '8'. Also I've adopted the "common-debian.sh" which @Chuxel mentioned to improve the terminal.

[Chuxel]

Reviewed microsoft/vscode-dev-containers#685 and made some comments. I should also say that the discussion of pre-building some of this into an image is also a good one. That won't happen automatically for the vscode-dev-containers repo. That said, a Dockerfile build will happen automatically - it just is usually faster if an image is pulled instead.

[psftw]

The PR above was merged, and based on a quick look, it seems reasonable to me. As mentioned above, VSCode handles the HLS install at runtime, so the diff between the official image and a "devcontainer" is a thin layer of common packages/configuration. This seems to be working as expected with the devcontainer being an independently maintained downstream image. Finding the right balance of what to publish under the haskell image name can be tricky. Is there a good use-case or demand for releasing a haskell:8-hls that bundled the appropriate GHC-matched release? Wouldn't VSCode still want to install the latest using the logic built into the extension? My understanding is that HLS is a generic backend designed to pair up with IDEs and other tools, but does it make sense to bundle on its own?

[jneira]

@psftw thanks for take a look to the merged devcontainer.

This seems to be working as expected with the devcontainer being an independently maintained downstream image.

Yeah and that downstream image already exists after the mentioned pr. I still see some value in host that downstream image in an place clearly associated with haskell like this and not only microsoft, to help its discovery.
Needed changes in the image will be easier to do if it lives here (i hope so! 😄), as all tools and dev teams involved live under the haskell github/haskell.org umbrella.

Is there a good use-case or demand for releasing a haskell:8-hls that bundled the appropriate GHC-matched release? Wouldn't VSCode still want to install the latest using the logic built into the extension? My understanding is that HLS is a generic backend designed to pair up with IDEs and other tools, but does it make sense to bundle on its own?

Well, the idea was include ghc, hls matching version on PATH and vscode (or vscodium) with the extensions already installed. The extension honours the hls executable in PATH as first option and anyways, as there is only one ghc in the system, it would not need another hls version.
That devcontainer could be used to start a project really fast, as all pieces will be preinstalled.