haskell / docker-haskell

Build	Status	Badges	(per-arch)

---

Haskell Docker Official Images

This is the Git repo of the Docker "Official Image" for haskell. See the Docker Hub page for the full readme on how to use this Docker image.

Image Details

Included Tools

• Glasgow Haskell Compiler (GHC).
• Cabal the CLI tool.
• Haskell Stack the CLI tool.

Operating System Support

Operating System	Support	Supported Versions	Support Variants
Debian	Yes	buster	standard, slim
Alpine	Planned	Last 2 releases	N/A
Windows	Planned	ltsc2022	windowsservercore, nanoserver

Processor Architecture Support

• amd64
• aarch64 (does not include Stack)

Installation Method

Cabal + Stack

Cabal and Stack release binaries for various platforms. These are downloaded and made available eg. copied into /usr/local/bin.

GHC

GHC releases an archive which includes scripts to install GHC. Once downloaded GHC is installed via:

• ./configure (we pass in additional paramters to the configure step)
• make install

The installed binaries are made availabe on the PATH.

Verification Method

Verification is done following the 'preferred' method for docker official images. This means we:

• Verify the release is published by the expected person via PGP key verification.
• Verify the sha256 of the release is as expected.

Version Support Policy

GHC

GHC minor versions (eg. 9.2) that are either actively being maintained (new patch releases will come out) or are still popular will be supported by these images. Once both of these are no longer true, support can be dropped. Users can still pull these images, however they will not be listed on the docker hub page and will no longer be updated with new Cabal and Stack versions.

Additionally, only the latest patch version of each major version of GHC will recieve further updates.

Cabal + Stack

For actively supported GHC versions, Cabal and Stack should be updated when new versions are relesaed.

Maintenance

Building + Running Locally

You can build and run the images locally with something like:

$ docker build -t haskell-local 9.2/buster && docker run -it haskell-local bash

Updating The Images

This invovles a 2 step process.

1. Update the images in the docker-haskell repository.
2. Update the official images repo to use the new git commit sha.

1. Update Dockerfiles

When a new version of Cabal, Stack or GHC is released the images need to be updated. In general this involves:

1. Update to the new version in the Dockerfile.
2. Updating the sha256 to the new version of the tool, for all supported processor architectures.
3. Update the PGP key, if the person doing the release has changed.

GHC

1. Replace the old and new GHC version globally eg. 9.4.3 becomes 9.4.4. This will update both Dockerfiles and the github actions.
2. Obtain the new sha256 for the new GHC binary distribution via https://downloads.haskell.org/~ghc/9.4.4/SHA256SUMS . Look for the sha for the .tar.xz supported versions (currently x86_64-deb10 + aarch64-deb10).
3. Replace globally the old sha256 for these with the new one obtained in step 2.
4. Update the PGP key if the person doing the release has changed. You can build the image locally at this point to see if it works or not. If it fails you need to update the PGP key. You need to find the key from the person doing the release on the ubuntu keyserver. See below for known releasers.

• Ben Gamari
• Zubin Duggal
• Bryan Richter

An example

Cabal

1. Replace the old and new cabal version globally eg. 3.6.2.0 becomes 3.8.1.0.
2. Obtain the new sha256 for the new cabal binary distribution via https://downloads.haskell.org/~cabal/cabal-install-3.8.1.0/SHA256SUMS . Look for the sha for the .tar.xz supported versions (currently x86_64-linux-deb10 + aarch64-linux-deb10).
3. Replace globally the old sha256 for these with the new one obtained in step 2.
4. Update the PGP key if the person doing the release has changed. You can build the image locally at this point to see if it works or not. If it fails you need to update the PGP key. You need to find the key from the person doing the release on the ubuntu keyserver. See below for known releasers.

• Mikolaj Konarski
• Hécate

An example

Stack

1. Replace the old and new stack version globally eg. 2.9.1 becomes 2.9.3.
2. Obtain the new sha256 for the new stack binary distribution via https://github.com/commercialhaskell/stack/releases/tag/v2.9.3 . Look for stack-2.9.3-linux-x86_64.tar.gz.sha256 + stack-2.9.3-linux-aarch64.tar.gz.sha256 files in the assets list.
3. Replace globally the old sha256 for these with the new one obtained in step 2.
4. The stack PGP key does not change so can be left as is.

An example (this also enabled aarch64 for stack, so has a bit more noise but you get the idea).

2. Release New Versions

Images are built and released by the central docker official images system. Specifically haskell is maintained in this file. See the docs on this format.

1. Determine which docker haskell image GHC versions have been impacted by the unreleased changes (stack + cabal bumps impacts all versions, GHC just impacts specific versions).
2. Update the GitCommit in the haskell file.
3. Update the Tags if these have changed.
4. Create a PR, including info on what has changed. The official images people will review the actual Dockerfile changes as they want official images to maintain a high level of quality.
5. Once merged, their build system will run and the image updates will eventually be released.

This doc describes the process in more detail.

Update Docker Hub Docs

The docker hub haskell docs live in a separate repo.

Image Tests

Functionality Tests

The image tests live in the official-images repo. They are run against amd64 and aarch64 in this repo. When updating haskell in the official images repo they are only run against amd64.

Dockerfile Linting

This is done via hadolint. We should not be afraid to ignore hadolint rules globally if required as it is not really designed for the official images which have some nuances.

docker-haskell's Issues

Alpine linux version?

I have been working on an image that uses Alpine, and I was wondering if i submitted a PR, it would be welcome. Of course I will change it however it needs to meet standards, I just want to know before I do the work to make it.

ghc-8.10.3

• First of all, thanks for the great work done here
• We are using the docker image in circleci to test haskell-language-server and we are trying to add support for ghc-8.10.3 so it would be great to get that version in the docker image
• Thanks in advance!

Stack changes incoming

Stack is evolving ❤️ https://github.com/commercialhaskell/stack/releases/tag/v2.3.0.1
Need to carefully review/test how 2.3 will impact us.

Build for Multi-Arch failing (arm64 / aarch64)

I'm getting below error on a multi-arch build with the Dockerfile from this repo:

docker buildx build --platform linux/arm64,linux/amd64 .

Seems to be only on the arm64 architecture - saw some hints on haskell/cabal#7950 but haven't been able to solve this

#0 261.3 Installing library in /opt/ghc/8.10.7/lib/ghc-8.10.7/ghc-8.10.7
#0 263.4 "/opt/ghc/8.10.7/lib/ghc-8.10.7/bin/ghc-pkg" --force --global-package-db "/opt/ghc/8.10.7/lib/ghc-8.10.7/package.conf.d" update rts/dist/package.conf.install
#0 265.6 ghc-pkg: Couldn't open database /opt/ghc/8.10.7/lib/ghc-8.10.7/package.conf.d for modification: {handle: /opt/ghc/8.10.7/lib/ghc-8.10.7/package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)
#0 265.6 make[1]: *** [ghc.mk:985: install_packages] Error 1
#0 265.6 make: *** [Makefile:51: install] Error 2

Any options to pass in configure flags?

servant-api example to be updated with a version of stack that uses `package.yaml` files

Given that the servant-api example is 4 years old should it be updated to use an hpack package.yaml file instead of a cabal file?

Add docker image with GHCup and/or HLS for use with devcontainers

The devcontainer configuration mentioned here #41 no longer works out-of-the-box because the Haskell VS Code extension now depends on GHCup to automatically install HLS.

One can still install GHCup or download the relevant HLS, but the experience is not ideal. If I install GHCup, it ends up installing another GHC and cabal 🤷

Bump stack to 2.11.1

Haddock can't find link destinations

I use the images to build and test my projects continuously, which works fine. However, when trying to invoke cabal haddock, it can't find link destinations for basic internal types like GHC.Types.IO.

I tried to generate a minimal example:

memowe@machine:~$ docker run -ti --entrypoint /bin/sh haskell:9.2.5

# cabal user-config update
Config file path source is default config file.
Config file not found: /root/.cabal/config
Writing default configuration to /root/.cabal/config
Renaming /root/.cabal/config to /root/.cabal/config.backup.
Writing merged config to /root/.cabal/config.

# cabal update
Downloading the latest package list from hackage.haskell.org
Package list of hackage.haskell.org has been updated.
The index-state is set to 2023-01-04T10:31:13Z.

# mkdir /tmp/foo
# cd /tmp/foo	
# cabal init --non-interactive --lib
The name foo is already in use by another package on Hackage.
[Log] Guessing dependencies...
[Log] Using cabal specification: 3.8
[Warning] unknown license type, you must put a copy in LICENSE yourself.
[Log] Creating fresh file CHANGELOG.md...
[Log] Creating fresh directory ./src...
[Log] Creating fresh file src/MyLib.hs...
[Log] Creating fresh file foo.cabal...
[Warning] No synopsis given. You should edit the .cabal file and add one.
[Info] You may want to edit the .cabal file and add a Description field.

# cabal haddock --haddock-hyperlinked-source
Resolving dependencies...
Build profile: -w ghc-9.2.5 -O1
In order, the following will be built (use -v for more details):
 - foo-0.1.0.0 (lib) (first run)
Configuring library for foo-0.1.0.0..
Preprocessing library for foo-0.1.0.0..
Running Haddock on library for foo-0.1.0.0..
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: base-4.16.4.0, ghc-bignum-1.2,
ghc-prim-0.8.0
Warning: --source-* options are ignored when --hyperlinked-source is enabled.
   0% (  0 /  2) in 'MyLib'
  Missing documentation for:
    Module header
    someFunc (src/MyLib.hs:3)
Warning: MyLib: could not find link destinations for:

	- GHC.Types.IO
Documentation created:
/tmp/foo/dist-newstyle/build/x86_64-linux/ghc-9.2.5/foo-0.1.0.0/doc/html/foo/index.html

Am I missing something here? What did I do wrong?

Drop official support / updates for debian 9

Just when I was ready for some quiet time around here.. ;)

So it seems as of cabal-install 3.6.2.0 it no longer supports debian 9.

We could keep updating deb 9, but leave cabal on 3.6.0.0 or we could drop support. My inclination is to drop support as it could be confusing having differing versions of cabal in stretch vs buster.

The docs state Additionally, we support the two most versions of Debian (stable and oldstable) as variants, with the most recent being the default if not specified.. oldstable is buster at this point with bullseye being released. Although cabal, ghc and possibly stack do not support deb 11 yet.

Anyway, I propose to remove deb 9 from the listed images and no longer update them. Then add deb 11 once haskell ecosystem supports it.

@psftw No rush on this one, but what do you think?

Include language server

One needs to install GHCup and HLS on the host environment to be able to use HLS on VSCode. Also, while the VSCode plugin can manage automatic installation of the HLS, mapping Haskell version to supported HLS version has to be done manually on each project.

It would be great to include supported and matching HLS version in the docker image itself. By using VSCode devcontainers one can then launch docker container and get HLS features out of the box.

Assuming HLS is available within the image, one can easily launch a devcontainer in VSCode following these steps:

Pre-requisites:

• A working docker installation on the host (or docker plugin on VSCode)
• Enable Docker CLI for the non-root user account (typically achieved by adding user to docker group) or be able to run VSCode as root (not recommended)
• A working VSCode installation with:
  a. Haskell and Haskell Syntax Highlighting extensions (with manual HLS option and no need to install GHCup)
  b. Devcontainer extension

Project setup:

• Create project folder structure as needed on the host.
• Inside the project root folder, create a folder called .devcontainer
• create a file called devcontainer.json inside the .devcontainer folder and add the following content:

{
    "image": "haskell:9-slim-buster",
  
    "customizations": {
      "vscode": {
        "extensions": ["haskell.haskell", "justusadam.language-haskell"]
      }
    }
}

Launch VSCode and open the project folder. VSCode will detect the devcontainer json and prompt reloading the project in devcontainer, and will launch it once accepted. One can now start developing in ghc with syntax highlighting and other HLS features.

I have managed to get this working on my ubuntu desktop. However, there are some observations:

• HLS debian binary is not available for aarach64, so adding HLS to Dockerfile will break aarch64 image build. Can be fixed by adding HLS aarch64 debian binary to the repository
• HLS binaries include support for multiple GHC versions. By modifying HLS make file, ghc version specific binary may be installed in the image. This will make development environment consistent and also significantly reduce image size.

I can submit a PR for Dockerfile, attached a working sample here

Include llvm in image

Would it be an option to include the relevant llvm version of a particular version of ghc? Newer versions of host operating systems don't have older llvm versions in the repository, in that case the haskell docker image comes in handy

failed to load cache key: invalid empty config file resolved for docker.io/library/haskell:7.8

Hi. Maybe this is not a proper place to report this issue, but not sure where else to put it. I can successfully install latest version, but not 7.8. The reason I want to install 7.8 is because it is last known version which works for pappy

Dockerfile:

FROM haskell:7.8

Build fails:

 docker build -t haskell .
 => ERROR [1/1] FROM docker.io/library/haskell:7.8@sha256:180dd57f1a2161fead508af82f204f0866a3a3ef11ab5cba643558d52d0abff2                                                                             0.0s
 => => resolve docker.io/library/haskell:7.8@sha256:180dd57f1a2161fead508af82f204f0866a3a3ef11ab5cba643558d52d0abff2                                                                                   0.0s
------
 > [1/1] FROM docker.io/library/haskell:7.8@sha256:180dd57f1a2161fead508af82f204f0866a3a3ef11ab5cba643558d52d0abff2:
------
failed to load cache key: invalid empty config file resolved for docker.io/library/haskell:7.8@sha256:180dd57f1a2161fead508af82f204f0866a3a3ef11ab5cba643558d52d0abff2

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

• 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 haskell/haskell-language-server#344

//cc @ndmitchell @emilypi @hmemcpy

x86_64 Windows support

Note: the original GitHub repository was deleted recently, so we've lost all the issues/discussion 😢

Windows is supported upstream, so we should have a Windows variant!

aarch64 Linux support

Note: the original GitHub repository was deleted recently, so we've lost all the issues/discussion 😢

We should support an aarch64 variant in addition to x86_64 as soon as it is feasible.

ARM support has been improving in upstream GHC, and with 8.8.1 there are now binaries being published, even though they are not officially supported. I ran in to problems bootstrapping Cabal, and noticed other issues in the GHC issue tracker which makes an 8.8.1 docker image difficult to put together at this time.

137 exit status on Cabal package installations with DOCKER_DEFAULT_PLATFORM=linux/amd64 on an M1 Mac

Hello!

My goal is to prepare a linux/amd64 Docker image using DOCKER_DEFAULT_PLATFORM on an M1 Mac, but cabal seems to fail to install any package.

For example, running DOCKER_DEFAULT_PLATFORM=linux/amd64 docker run -it --rm haskell:9-slim bash -c "cabal update && cabal install array"; echo $? prints 137 indicating an out-of-memory error (even though I have made 12 GB of memory available to Docker). (I arbitrarily picked the array package since it has no dependencies (except for base), but any package that I've tried has failed.)

The cabal-install version is 3.6.2.0.

I'm using a fully updated M1 MacBook Pro (14-inch, 2021) with an Apple M1 Pro chip, 16 GB of RAM and macOS Monterey.

I have the latest version of Docker Desktop (4.9.1). The Docker version is 20.10.16 (build aa7e414).

I have tried both version 8 and version 9 of the images (with and without “-slim”).

Thanks!

Add ghc 8.10.6

https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html

Will require Debian support for ghc 8.10.6 in https://downloads.haskell.org/debian/

Request for Debian bullseye/stable-based images

Debian 11 "bullseye" came out in August 2021, and at that point stable came to mean Bullseye, and oldstable to mean Buster.

hub.docker.com/_/haskell says

we support the two most versions of Debian (stable and oldstable) as variants

This is currently not correct. Please consider providing bullseye-based images. Thanks!

Fix example projects

Note: the original GitHub repository was deleted recently, so we've lost all the issues/discussion 😢

The examples have become neglected. Ideally we should have a couple of simple example projects that cover the usage of cabal and stack with basic cache optimization for a developer workflow. These should be executed by CI or at least smoke tested as part of the release process.

9.4.5 doesn't include the correct GHC

Running stack build with the following stack.yaml:

resolver: lts-21.0

downloads ghc-tinfo6-libc6-pre232-9.4.5, instead of using the one built into the container.

Need CONTRIBUTING docs

There are a number of subtle or unwritten conventions around what/why/how this image works. The official images documentation is quite extensive and provides context on some of the "why" and "how". The "what" is loosely covered in the published docs which is also in a separate repository. This is a lot of up-front work to get involved, and if some detail is missed it can lead to wasted efforts. We should continue to refer to the above links in our documentation here, but additional contributing guidelines covering some key ideas would go a long way.

Update GHC 9.4 to version 9.4.5

Download: https://downloads.haskell.org/ghc/9.4.5/
Blog: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html

Fix flaky image build

Note: the original GitHub repository was deleted recently, so we've lost all the issues/discussion 😢

Building this image is difficult due to issues with GnuPG and key servers. More details in https://github.com/docker-library/faq#openpgp--gnupg-keys-and-verification

The most straight-forward solution would be to directly embed the keys in this repository, though this is not ideal.

No compiler found, expected minor version match with ghc-8.10.4 (x86_64-tinfo6)

Hi. Thanks for maintaining this repo. I have following Dockerfile:

## Dockerfile for a haskell environment
FROM haskell:8

# Configure apt
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
    && apt-get -y install --no-install-recommends apt-utils 2>&1

# Install haskell ide engine dependencies
RUN apt-get -y install libicu-dev libtinfo-dev libgmp-dev zlib1g-dev
RUN stack config set system-ghc --global true
RUN stack install --system-ghc hls

# Clean up
RUN apt-get autoremove -y \
    && apt-get clean -y \
    && rm -rf /var/lib/apt/lists/*
ENV DEBIAN_FRONTEND=dialog

# Set the default shell to bash rather than sh
ENV SHELL /bin/bash

When I build image I get this error:

 => CACHED [4/7] RUN stack config set system-ghc --global true                                                                                                                                         0.0s
 => ERROR [5/7] RUN stack install --system-ghc hls                                                                                                                                                     2.0s
------
 > [5/7] RUN stack install --system-ghc hls:
#8 0.443 Writing implicit global project config file to: /root/.stack/global-project/stack.yaml
#8 0.444 Note: You can change the snapshot via the resolver field there.
#8 1.138 Using latest snapshot resolver: lts-17.7
#8 1.905 No compiler found, expected minor version match with ghc-8.10.4 (x86_64-tinfo6) (based on resolver setting in /root/.stack/global-project/stack.yaml).
#8 1.905 To install the correct GHC into /root/.stack/programs/x86_64-linux/, try running "stack setup" or use the "--install-ghc" flag. To use your system GHC installation, run "stack config set system-ghc --global true", or use the "--system-ghc" flag.
------

I can workaround this issue by installing 8.4.10 ghc via stack, but it would be nice if this would work out of the box.

The PATH environment variable does not contain the path to ghc when using docker-compose

How to reproduce

Given the following compose file

version: '2.3'

services:
  build:
    image: haskell:9.2.1
    volumes:
      - .:/usr/app
    command: bash -lc "printenv && cd /usr/app && cabal init"

When I run

COMPOSE_FILE=<name-of-compose-file>.yml docker-compose run --rm build

Epected

Then cabal initialises a project and /opt/ghc/9.2.1/bin is in the PATH environment variable that is printed

Actual

Then cabal fails with The program 'ghc' version >=7.0.1 is required but it could not be found.
And the PATH is printed as PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Add image for GHC 9.6

GHC 9.6.1 was released on Mar 10: https://www.haskell.org/ghc/download_ghc_9_6_1.html

arm64 does not include stack

Stack has had patchy support of arm64 in the past, but it is not officially supported.

The last released binary is for stack 2.7.1, however I get this failure on debian buster.

There are unofficial binaries that ghcup uses, but I don't think official images should include anything unofficial.

Add myself as maintainer

Hi,

I'd be happy to help maintain this in terms of reviewing / merging PRs and updating docker hub. I might need some instruction on how to update the official image on docker hub.

Cheers

Continually blocked on upstream packages

To update to a new ghc / cabal version they need to be available in Debian first. Unfortunately there is a lot of lag from when the new versions are released to when they appear as debian packages. This seems to be due to @hvr being the sole person responsible for the packaging, but often not being available to do this work.

This is not a criticism of @hvr who has given a tremendous amount to the Haskell ecosystem ❤️ , but it is just a reality that there is consistent lag here.

Options

Try to improve the situation around debian package updates

We could chase this up with https://github.com/haskell-CI/haskell-ci which is the home of the debian/ubuntu packages. We could also pull in the Haskell foundation who may have ideas.

Switch to ghcup

Ghcup does not depend on these same debian packages and does promptly add new versions. I've been playing with what this might looking like.

Pros

• New versions of cabal, ghc and stack are promptly added.
• Once mechanism for installing cabal, ghc and stack.
• Removes some complexity of the installation from these images.
• Ghcup is further consolidated as the one true way (excluding stack) of installing ghc / cabal. Haskell github actions are also using ghcup. Actually, it seems it uses the hvr ubuntu PPA where possible, then falls back to ghcup?
• Ghcup has (preliminary?) support for windows, so it provides a path to a windows docker haskell image.
• I believe ghcup has ARM support, so could help support arm.
• We could support more linux distros that ghcup supports if we want ie. alpine

Cons

• Ghcup is not a great fit for docker. Ghcup is a tool to manage many versions of tools, when in docker we only want to provide one exact version. Thus it is additional bloat + complexity when it shouldn't in theory be required. For this reason I believe no other official programming language images are using an equivalent tool.
• Ghcup installs for the current user, where as in docker we want to install for all users. For example a common pattern in docker is to switch to a new user with less privileges. However, this new user cannot use ghc / cabal / stack that were installed for a different user by ghcup. There may be ways to work around this, potentially requiring ghcup changes.

Conclusion

???

Not sure, ghcup is a bit of a poor fit philosophically, however may be a great pragmatic choice resulting in a net win. If we do not go with ghcup, I think we should attempt to improve the lag problem with the current debian packages.

@psftw @hasufell any thoughts?

Add ghc 8.10.5

Will require Debian support for ghc 8.10.5 https://downloads.haskell.org/debian/

Cannot find -lnuma when building executables on arm64 image

Building executable on arm64 image fails with cannot find -lnuma error.

% docker run --platform linux/arm64 -it haskell:8.10.7 bash
root@d04edf654535:/# echo "main = return ()" > test.hs
root@d04edf654535:/# ghc test.hs
[1 of 1] Compiling Main             ( test.hs, test.o )
Linking test ...
/usr/bin/ld.gold: error: cannot find -lnuma

rts/posix/OSMem.c:370:0: error:
     error: undefined reference to 'mbind'

rts/posix/OSMem.c:748:0: error:
     error: undefined reference to 'numa_num_configured_nodes'

rts/posix/OSMem.c:758:0: error:
     error: undefined reference to 'numa_get_mems_allowed'

rts/posix/OSMem.c:748:0: error:
     error: undefined reference to 'numa_num_configured_nodes'

rts/posix/OSMem.c:763:0: error:
     error: undefined reference to 'numa_bitmask_free'

rts/posix/OSMem.c:748:0: error:
     error: undefined reference to 'numa_num_configured_nodes'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

This can be fixed by installing libnuma-dev.

I think it would be friendly if libnuma-dev is installed by default.

Looking for Maintainers

Note: the original GitHub repository was deleted recently, so we've lost all the issues/discussion 😢

This project has become a bit neglected over the years. I've responded to issues and kept the release train rolling, though sometimes it can take a few extra weeks to catch up. I'm seeking a motivated Haskell enthusiast to take over and steer the ship more proactively.

Interested? Check out the open issues and read up on the Official Images process. An ideal candidate is connected to one or more upstream projects or uses Haskell at their job and has a long term interest in supporting this Docker image for the community.

Update official 9.8 images

The images haven't been updated following the latest PR. Running e.g. podman run --rm -it docker.io/haskell:9 cabal --version returns cabal-install version 3.8.1.0, which #114 upgraded to 3.10.2.

If I understand the instructions in the README correctly, lines 7 and 12 of the official library definition need to be updated, as they still point to commit 30f9d37 from last September:

-GitCommit: 30f9d37242fd2ab6a8cf23e546a26b56a0d2636c
+GitCommit: 3d23b935d1de92b907c24b3183a0ee8cdeb459cf

I'm don't expect the docker-library repo to accept contributions from strangers, so I thought I'd post here first. The 9.4 tag has been updated following #115, so it looks like only the last PR was skipped.

Release 8.8.2/3 to docker hub

Hi,

It seems that 8.8.2 / 3 versions are now supported, however they haven't been released to the docker hub registry. Can this be done? Happy to help if there is a PR needed somewhere.

linux/arm64/v8 architecture support

Currently, this package is only built for linux/amd64. Is support for linux/arm64/v8 planned? I understand GHC at least can be compiled on ARM64, now. I'm not sure what state it's actually in, in terms of actually working.

GHC 8.10.1

haskell:run image

I think it would be nice to have images like haskell:run-9.2.1-buster which has the core packages required to run a haskell binary compiled with a given version + platform.

Something like:

FROM debian:buster-slim

RUN apt-get update \
 && apt-get install -y --no-install-recommends \
    libgmp10 \
    ca-certificates \
 && rm -rf /var/lib/apt/lists/*

Official Devcontainer feature and template

Community members have tried building a devcontainer #41

The result at that time was: https://github.com/microsoft/vscode-dev-containers/tree/main/containers/haskell

However, the repo microsoft/vscode-dev-containers is now archived. The Microsoft team split this repository into the Devcontainer feature and the Devcontainer template.

So now we may need a Haskell Devcontainer feature and a Haskell Devcontainer template.

In this list, there is already a haskell feature. Has the haskell community reviewed this devcontainer feature?

And there is currently no haskell devcontainer template available yet.

Looking for maintainers

I am currently the only maintainer.. 😅

Useful skills

Roughly in order of usefulness.

• Knowledge of Docker
• Knowledge of Haskell tooling
• Knowledge of operating systems

However, none of these are a hard requirement. The bumping of versions is a pretty simple process. Happy to pass on my knowledge if someone is interested but hasn't done much docker or whatever.

To make it clear, there is a very low level of knowledge required to get involved.

What do maintainers do?

Primarily, bump versions of GHC, cabal + stack when they are released. These are bumped first in this repo, then in the official images repo.

Otherwise, look for ways to improve the images, or add more OS support.

I am looking to step down

Update: I am looking to step down end of Jan 2023 (happy to stick around longer to advise if needed). I'll post this around and hopefully people are interested.

Update 2: I am around and will approve and merge PRs, but will not make any more commits in the hope that others will step up. At the latest I will leave the project end of 2023.

Next steps

If you are interested, let me know a bit about yourself and why you are interested. Then I think you can do the next version bumps that come along, or dive into other more thorny work if you want.

Install `-prof` packages?

It would make sense to have them in full images, but omit from -slim images.

I just run into a use case where I need -prof stuff.

opinions, @hvr @psftw?

Upgrade to debian buster

Request to upgrade the base-image from debian:stretch to debian:buster as the current stable release of debian. Maybe provide e.g. haskell:8.6.5-buster as to not break any existing tags and switch to buster as the default base-image when a new version of the haskell image (i.e. ghc) is released?

"RUN cabal install --only-dependencies -j4" fails with "Could not find module: <lib_module> with any suffix"

In the How to use this image section here, the following Dockerfile is given as an example:

FROM haskell:8

WORKDIR /opt/example

RUN cabal update

COPY ./example.cabal /opt/example/example.cabal

RUN cabal install --only-dependencies -j4

COPY . /opt/example
RUN cabal install

CMD ["example"]

However, when I try to build this image and it reaches the command RUN cabal install --only-dependencies -j4 cabal fails with an error saying "Could not find module: x with any suffix", where x is the first module listed in my cabal file under library -> exposed-modules.

So it looks like Cabal needs the source code files of my project to be present when running --only-dependencies and I don't understand why.

For reference, I'm using the haskell:8.8.4-buster image.

locale setting incorrect

locale -a
return

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
C.UTF-8
POSIX

affect hGet hPut like function

locale should set to C.UTF-8, to avoid fallback to ASCII since locale setting incorrect

Templating solution

With more variants being added it is becoming more desirable to have templating. #6 was one such attempt.

https://docs.earthly.dev/docs/earthfile is another option.

It would be nice to dogfood and use Haskell though.

Docker example fails to run

Hi everyone.

I just ran this example successfully:

docker run -it --rm haskell:8

However the second example does not work. Here is the Dockerfile:

FROM haskell:8
RUN stack install pandoc pandoc-citeproc
ENTRYPOINT ["pandoc"]

When I run docker build . I get this error:

$ docker build .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM haskell:8
 ---> 77fd2cbd6f87
Step 2/3 : RUN stack install pandoc pandoc-citeproc
 ---> Running in 90bd308cea32
Writing implicit global project config file to: /root/.stack/global-project/stack.yaml
Note: You can change the snapshot via the resolver field there.
Using latest snapshot resolver: lts-16.16
No compiler found, expected minor version match with ghc-8.8.4 (x86_64-tinfo6) (based on resolver setting in /root/.stack/global-project/stack.yaml).
To install the correct GHC into /root/.stack/programs/x86_64-linux/, try running "stack setup" or use the "--install-ghc" flag. To use your system GHC installation, run "stack config set system-ghc --global true", or use the "--system-ghc" flag.
The command '/bin/sh -c stack install pandoc pandoc-citeproc' returned a non-zero code: 1

I have tried several times with --system-ghc, but same error.

I've found a similar error on a Japanese stackoverflow question, but I could not follow the translated answer.

https://translate.googleusercontent.com/translate_c?depth=1&hl=en&prev=search&pto=aue&rurl=translate.google.com&sl=ja&sp=nmt4&u=https://ja.stackoverflow.com/questions/70001/no-compiler-found-expected-minor-version-match-with-ghc-8-8-4&usg=ALkJrhhFLe0WPLvjIFnYcS4vbT-87-dqjQ

I am trying to compile my stack project into a binary so I can copy it onto a server.

Thanks
Ben