haskell - change devcontainer to use GHCup

[gusbicalho]

(Some previous discussion at haskell/docker-haskell#76)

Problem

The existing devcontainer for haskell is based on the haskell images from https://github.com/haskell/docker-haskell. These images provide specific GHC/cabal versions, which is a good thing for reproducibility. However, those images do not include a binary for the haskell-language-server. The existing devcontainer relies on the Haskell extension automatically downloading haskell-language-server.

This no longer works. Since version 2.0.1 (released in 2022-04-27), the Haskell extension for VSCode depends on GHCup for downloading HLS. Therefore, any user who tries to use this devcontainer ends up getting error messages about missing GHCup or missing HLS.

Solution

Instead of starting from the haskell image, the devcontainer can start from a minimal Debian image, download and install GHCup and use that to manage GHC, HLS, Cabal and Stack.

The list of packages installed in the beginning of the Dockerfile was copied from one of the haskell Dockerfiles.

Q: Why not start from one of the haskell images? A: Because then we'd have extra GHC and cabal installations in the system, which are not managed by GHCup. This could be confusing for users trying to understand and modify the image; it also uses up space for no good reason.

Q: Do we really need to install GHC, cabal and stack while building the container? A: Not really. If we only install GHCup, the Haskell extension will prompt the user to install recommended versions of those tools. However, this prompt will only happen when the user first opens a haskell source file, and then they will have to wait until the installation is complete. To me it seems better to have a container that takes longer to build, but once built the user can quickly start working.

[ghost]

All CLA requirements met.

[gusbicalho]

I'd love to get a review from the people involved in #685 @jneira @stuartpike @eitsupi

[eitsupi]

I think you need to make some modifications to be consistent with other definitions.
(Note that I am not a haskell user and can only advise on general Dockerfile writing)

[gusbicalho]

@eitsupi thanks for the feedback!

Changes:

• Shaved some dependencies that were indeed installed by common-debian, or that did not seem to be really necessary (I was able build some small projects of mine without them)
• Moved the install of extra dependencies to happen after common-debian, which seems to be the recommended way
• Finally, I collapsed some RUN statements into && chains to reduce the number of layers.

Can you take another look?

[jneira]

Totally agree with the approach, ghcup is the way to go nowadays. F.e. hls is using ghccup as its primary channel of distribution.

[stuartpike]

There is discussion over at Haskell about how the community may get confused over ghcup stack and cable haskell-infra/www.haskell.org#191

I believe we need to understand who the remote docker container audience is before moving away from a general image maintained by Haskell.

Is the direction to focus on general Haskell learning or a production ready build environment?

[gusbicalho]

@stuartpike
The existing devcontainer image does not work at all right now (it does not include a HLS binary to power the VSCode Haskell extension). That's why I think it would be better to move on with the GHCup solution ASAP, and review the decision later if necessary.
Even if the community ends up settling on a different approach, at least we get a working template in the mean while. Makes sense?

[wolverian]

I believe we need to understand who the remote docker container audience is before moving away from a general image maintained by Haskell.

I for one would like to develop Haskell apps on an iPad on GitHub Codespaces.

The approach in this PR looks pretty good, since it installs both Cabal and Stack into the container. Using GHCup is sort of an implementation detail here, especially for Stack users, as they don’t need to care about GHCup at all. Stack will just do its thing.

[stuartpike]

When you use the container via a terminal type 'ghci' and you get the 'Prelude' command, that is how I started this open source container to get a minimal installation which can be enhance as needed.

As I've said previously, need to know the target audience to enhance this container. There will be many scenarios and possible solutions.

[gusbicalho]

Since this is the vscode-dev-containers repo, I think the priority should be to have a Dockerfile that enables Haskell development in VSCode out of the box.

Because of the change to the Haskell extension, the current status quo no longer works for this goal. Having a Dockerfile here that does not work ends up misleading people, so I think we should fix this.

I'm not sure how to proceed to get a decision so we can move forward with this or some other solution.

(edit: removed duplicated sentence)

[hasufell]

@stuartpike there's no controversy about installation method in the Haskell community anymore. Cabal vs stack is an orthogonal topic. GHCup allows to install either of them.

[stuartpike]

@stuartpike there's no controversy about installation method in the Haskell community anymore. Cabal vs stack is an orthogonal topic. GHCup allows to install either of them.

So the container has ghci and cabal installed and for use of stack just enter in the terminal 'stack ghci'

What type of development are you wanting to do with this?

• building and packaging Haskell libraries and programs (cabal)
• build Haskell projects and manage their dependencies (stack)

[hasufell]

@stuartpike there's no controversy about installation method in the Haskell community anymore. Cabal vs stack is an orthogonal topic. GHCup allows to install either of them.

So the container has ghci and cabal installed and for use of stack just enter in the terminal 'stack ghci'

What type of development are you wanting to do with this?

• building and packaging Haskell libraries and programs (cabal)
• build Haskell projects and manage their dependencies (stack)

There is no difference in use case for stack and cabal.

[gusbicalho]

What type of development are you wanting to do with this?

• building and packaging Haskell libraries and programs (cabal)
• build Haskell projects and manage their dependencies (stack)

The README in this repo says:

This repository contains a set of dev container definitions to help get you up and running with a containerized environment. The definitions describe the appropriate container image, runtime arguments for starting the container, and VS Code extensions that should be installed. Each provides a container configuration file (devcontainer.json) and other needed files that you can drop into any existing folder as a starting point for containerizing your project.

I read "starting point" and I think of something that helps beginners as much as possible out-of-the-box, assuming expert users can figure out what environment they want and customize their Dockerfile however they want. The Dockerfile is copied to each git repo, and the Docker image is built from scratch every time a user creates a Codespace anyway, so the cost for a user to change they env is minimal.

I could change the template to add ARGs like INSTALL_STACK or CABAL_VERSION so that more of the configuration can be done via the devcontainer.json file. However, I'm not sure that is very helpful: in my (very limited) experience using devcontainers it is actually easier to comment out or change stuff in the Dockerfile than to figure out where to add the right arguments in the devcontainer.json.

[ulysses4ever]

Dear all, I’m using and contributing to Haskell for about 11 years. Lately I’ve been helping Cabal maintenance. I came here from a Cabal issue where the author was complaining about the defunct Haskell devcontainer.

The approach of this PR is a perfectly sane one from today's Haskell development perspective, and, most importantly, it fixes the currently defunct container. I, as a part of the Cabal team, join the representatives of the other critical Haskell infrastructure projects — @jneira, an HLS (the Haskell Language Server) developer, and @hasufell, the primary GHCUp developer, — in asking you, respected devcontainers maintainers, to get this PR merged.

Please, let me know, what else people with Haskell expertise can provide you with. The question about “scenarios this can be used in” doesn’t look productive and only invites the obvious answer: any. Any moderately complicated pure Haskell project can be covered by the current approach. The only kind of exception I can think of is huge projects like GHC (the Haskell compiler itself) that are not purely Haskell and are not built with Cabal or Stack. But that’s an expected omission (and I’m not really sure that it is indeed an exception: maybe you can make it work).

Please, let’s be constructive and try to narrow down the questions to something actionable. Otherwise, we’ll have this PR linger on for many more months than it should be. Really, it should have been merged back in May, so that maintainers of projects like Cabal, HLS, GHCUp don’t get persistent reports about defunct containers.

[stuartpike]

Okay so over to Microsoft to merge as I don’t have the power to merge into Microsoft’s branch.

[bamurtaugh]

Thanks for opening!

As a heads up, our team has been actively focused on an updated plan for community contributions and this repo moving forward, which we've now outlined in this issue: #1589. This includes moving to a couple new repos for images (https://github.com/devcontainers/images) and Features (https://github.com/devcontainers/features).

We anticipate to have a similar repo and distribution process for templates/definitions. We'll keep everyone updated (likely via another issue in this repo or comment on #1589) when our new templates repo is available and the process is defined.

Please let me know if you have any questions, thank you!

[gusbicalho]

Hi @bamurtaugh thanks for the info!
Does this mean we cannot merge this PR, and we have to wait for the new template process?

[bamurtaugh]

No problem! And yes, we'd hold off on merging this PR as this repo will eventually be archived, except for security patches.

[gusbicalho]

Right. I will close this PR then.
@bamurtaugh if I open a PR simply removing the existing container, would that be accepted? I think this would be better than the status quo, since it is causing people to mistakenly open issues in other Haskell projects.

[bamurtaugh]

Thanks @gusbicalho!

@Chuxel what do you think about removing? It seems reasonable based on the above info:

This no longer works. Since version 2.0.1 (released in 2022-04-27), the Haskell extension for VSCode depends on GHCup for downloading HLS. Therefore, any user who tries to use this devcontainer ends up getting error messages about missing GHCup or missing HLS.

But we'll also be discussing what to do with contributions in this repo that don't end up as part of the new repos, so perhaps we hold off until we can share a more definite plan.

[gusbicalho]

But we'll also be discussing what to do with contributions in this repo that don't end up as part of the new repos, so perhaps we hold off until we can share a more definite plan.

Alright, I will wait a little before closing this PR then.

[Chuxel]

@bamurtaugh I think we could tactically merge given it is broken as-is and the new process has not yet been disclosed.

@gusbicalho Thie new approach will be like Features which will allow anyone to contribute at any time - templates will end up in an OCI Artifact repository like GHCR. This has taken longer than we expected, so thanks for the patience.

You could also consider contributing a Feature for Haskel near term that can then be added to any image. Info on creating, publishing and contributing a Feature can be found in the public template https://github.com/devcontainers/feature-template