The Docker images hosted at ocaml/opam2 have now been updated to include the latest OCaml 4.08.0 release as well as the snapshots of 4.09 and 4.10.
One sideeffect of this is that the ocaml/opam2 default image now has OCaml 4.08 as its default switch. If you use it in CI, it may suddenly give you errors if your code has not yet been ported to work with that new release.
As a reminder, you can pin the OCaml version you use in CI easily by:
running opam switch 4.07 as the first command in the Dockerfile after FROM ocaml/opam2.
using the ocaml/opam2:4.07 image instead of the default one. This image also includes several other 4.07.0 variants (such as afl, flambda and so on), which you can list with docker run ocaml/opam2:4.07 opam switch.
As always, please get in touch with me if you see any other breakage from these image updates.
Another update: the base distributions of the ocaml/opam2 images have also been updated to support Fedora 30, Alpine 3.10, OpenSUSE Leap 42.1 and also the impending Debian 10 (Buster) release. We have also deprecated Fedora 27/28, Ubuntu 14.04 and Alpine 3.8 in favour of the newer releases. The 4.09 switches also reflect the recently released 4.09+beta1 snapshot.
There have been a few requests for ‘slimmer’ images that use up less disk-space. The reason the existing ones are so big is that each container has multiple precompiled compilers (either multiple major releases, or feature variants such as flambda or afl). This is really useful for continuous integration, but is less ideal if you just want a quick OCaml compiler container to build some software on your QubesOS laptop.
In order to accommodate both usecases, I’m going to resurrect the ocaml/opam containers for the “slim” usecase. The containers in ocaml/opam are currently deprecated while we did the opam2 release, but now that is out of the way we can remove the opam1 containers. Over the next few months, we’ll have ocaml/opam containers with minimally sized toolchains for production compilation use, and the ocaml/opam2 containers will continue to be maintained unchanged for CI use.
As always, more feedback or usecases welcome to help guide the evolution of this infrastructure.
Thanks for maintaining the images! We use them for CI (and then start from the respective base image to make deployment images, which given Dockers support for multi-images is pretty nice).
As a small sidenote, maybe some renaming would be useful, otherwise it is very confusing that “opam2” is the “fat” Docker images and “opam” is not OPAM 1.x but rather “slim” OPAM 2 images.
Glad to hear that the images are useful! I agree about the renaming, but it has to be done in very slow motion since there is no support for redirections in the Docker Hub. So my approach has been to deprecate ocaml/opam slowly and matching the pace of the opam 1.x deprecation.
In the long term, we can also deprecate ocaml/opam2 and have ocaml/opam be the long term home of the opam packages. Need to think through what the tag namespace looks like. The defaults could be the “slim” images (with no compiler variants), and a -variants tag suffix could indicate that the images will be bigger and of more applicability to CI systems. Other ideas welcome for layouts.
I find these Docker images very useful as well, thank you! I’ve been using opam2 Alpine variant in multiple projects for statically linked release builds, and Ubuntu in another one, with great success.
A slim variant would be pretty handy. Most of the time I switch to the upstream opam repository and create my own switches, and don’t really utilize what comes bundled in these images.
One existing solution to this are the intermediate -opam images which are built before opam-repository and ocaml are installed:
docker pull ocaml/opam2:alpine-3.10-opam
These just have the opam binary installed and the build tools for that OS necessary to compile OCaml. You could, depending on your CI, switch to the upstream opam repository and create your own switches and cache the result without pulling down the fatter images.
Since we’re discussing it: can you point out where the Dockerfiles of the opam2 repo are? I was trying to figure out which respective base images they use but couldn’t find them at all. The old Docker repo had a link to a Github repo but for the new one there is no pointer on where to go.
This might make it a bit easier to see everything in once place, since the whole process is coordinated by a single OCaml process, rather than by generating Git commits that trigger more builds elsewhere.
What platforms do you need +static+musl on? If you’re in a Docker container, then this can be accomplished by using the existing alpine images and adding -static to the dune-workspace file.
E.g. something like
FROM ocaml/opam2:alpine
RUN echo "(lang dune 1.11)" > dune-project
RUN echo "(name duniverse)" >> dune-project
RUN echo "(lang dune 1.11)" > dune-workspace
RUN echo "(env (_ (flags -cclib -static)))" >> dune-workspace
RUN opam exec -- dune build @install
This will build static binaries with musl, since Alpine Linux uses musl as its base libc.
A few infrastructure problems have blocked the update of the ocaml/opam2 images (the Docker Hub basically refuses to let us delete images).
There are up-to-date images under https://hub.docker.com/r/ocurrent/opam/tags which are up-to-date and are slimmer (that is, they do not include all the variants of a compiler in a given image, as ocaml/opam2 did).
I’ll post here when I figure out how to fix ocaml/opam2 sensibly…
Given that Docker Hub is a central point for most people using Docker this seems like a very reasonable approach from them as others might have built and deployed things into production based on images and tags that have been published.