haskell pulls statistics

Quick reference

• Maintained by: the Docker Community • Where to get help: the Docker Community Slack, Server Fault, Unix & Linux, or Stack Overflow

Supported tags and respective Dockerfile links

• 9.14.1-bookworm, 9.14-bookworm, 9-bookworm, bookworm, 9.14.1, 9.14, 9, latest • 9.14.1-slim-bookworm, 9.14-slim-bookworm, 9-slim-bookworm, slim-bookworm, 9-slim, slim • 9.12.4-bookworm, 9.12-bookworm, 9.12.4, 9.12 • 9.12.4-slim-bookworm, 9.12-slim-bookworm • 9.10.3-bookworm, 9.10-bookworm • 9.10.3-slim-bookworm, 9.10-slim-bookworm • 9.10.3-bullseye, 9.10-bullseye, 9-bullseye, bullseye, 9.10.3, 9.10 • 9.10.3-slim-bullseye, 9.10-slim-bullseye, 9-slim-bullseye, slim-bullseye • 9.8.4-bullseye, 9.8-bullseye, 9.8.4, 9.8 • 9.8.4-slim-bullseye, 9.8-slim-bullseye, 9.8.4-slim, 9.8-slim • 9.6.7-bullseye, 9.6-bullseye, 9.6.7, 9.6 • 9.6.7-slim-bullseye, 9.6-slim-bullseye, 9.6.7-slim, 9.6-slim

Quick reference (cont.)

• Where to file issues: https://github.com/haskell/docker-haskell/issues • Supported architectures: (more info) amd64, arm64v8 • Published image artifact details: repo-info repo's repos/haskell/ directory (history) (image metadata, transfer size, etc) • Image updates: official-images repo's library/haskell label official-images repo's library/haskell file (history) • Source of this description: docs repo's haskell/ directory (history)

What is Haskell?

Haskell is a lazy, functional, statically-typed programming language with advanced type system features such as higher-rank, higher-kinded parametric polymorphism, monadic effects, generalized algebraic data types (GADTs), flexible type classes, associated type families, and more.

Haskell's ghc is a portable, optimizing compiler with a foreign-function interface (FFI), an LLVM backend, and sophisticated runtime support for concurrency, explicit/implicit parallelism, runtime profiling, etc. Other Haskell tools like criterion, quickcheck, hpc, and haddock provide advanced benchmarking, property-based testing, code coverage, and documentation generation.

A large number of production-quality Haskell libraries are available from Hackage in the form of Cabal packages. The traditional cabal tool, or the more recent stack tool (available in 7.10.3+) can be used to streamline working with Cabal packages.

About this image

This image ships a minimal Haskell toolchain (ghc and cabal-install) as well as the stack tool (https://www.haskellstack.org/) where possible. stack does not currently support ARM64 so is not included for that processor architecture.

ARM64 support is new and should be considered experimental at this stage. Support has been added as of 8.10.7, 9.0.2 and 9.2.1.

Note: The GHC developers do not support legacy release branches (i.e. 7.8.x). Only the two most recent minor releases will receive updates or be shown in the "Supported tags ..." section at the top of this page.

Additionally, we aim to support the two most recent versions of Debian (stable and oldstable) as variants, with the most recent being the default if not specified.

Note: Currently stable Debian is version 11 bullseye, however it is not yet supported by Haskell tooling. Until that time the default will remain Debian 10 buster. We have dropped support for Debian 9 stretch.

How to use this image

Start an interactive interpreter session with ghci:

Dockerize an application using stack:

Dockerize an application using cabal:

Iteratively develop a Haskell application with a Dockerfile utilizing the build cache:

Considerations for happy, alex, etc

Some packages that also act as build dependencies, such as happy and alex, are no longer included in this image (as of haskell:8.2.2 & haskell:8.4.3). There is a bootstrapping problem where one or more of these tools may be assumed to be available. If you run in to an error about missing dependencies that are not explicitly called out in a Cabal package, you will need to explicitly mark them for installation.

Considerations for Stack

The Stack tool is primarily designed to run directly on the host and comes with many advanced features such as GHC bootstrapping and Docker integration. Within the context of a container image, some of these features (stack docker) clash with the Docker abstraction and should be avoided.

Another common scenario that can be confusing is the default Stackage snapshot. A Stackage snapshot is a collection of Haskell packages pinned to specific versions for compatibility with a particular GHC release. When you ask Stack to resolve dependencies it refers to a particular snapshot via the resolver value. While you should be specifying a resolver explicitly in your projects, it is possible to run with the auto-generated default. That default is determined by the value obtained from the upstream Stackage server at the time it was requested, and points to the latest "LTS" snapshot. If the snapshot refers to a different version of GHC than is provided in the Docker image, you may see a message like the following:

In this case, the GHC release in the haskell Docker image got ahead of the default Stack resolver expected version of GHC. As the output suggests, manually setting the resolver (typically via stack.yml) is the recommended approach.

The alternative to use --install-ghc doesn't make sense in a Docker image context, and hence the global install-ghc flag has been set to false (as of haskell:8.2.2 & haskell:8.4.3) to avoid the default behavior of bootstrapping a new GHC in the container.

Image Variants

The haskell images come in many flavors, each designed for a specific use case.

haskell:

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.…

Description from the Docker Hub listing.