haskell / docker-haskell Goto Github PK

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!

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

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/*

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?

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.

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

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.

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.

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!

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.

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.

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.

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.

It would be great to have a GHC-9.10.1 image

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!

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

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.

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.

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

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.

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?

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.

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

• 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!

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

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?

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.

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.

It would be great to have a release with the new GHC 9.10 image added in #130

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

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?

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.

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

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.

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.

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/

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

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?

• 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

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?

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?

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

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 🤷

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.

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.