I completely agree that the state of “official” OCaml images is a little confusing. We’re working to improve that (e.g. we have a description for ocaml/opam we just haven’t put it on there yet…).
ocaml/opam are the correct, up to date images to use.
I believe the problem here is that the pipeline no longer builds Fedora 32 images, only Fedora 33 and 34. By the looks of things, the last time a Fedora 32 image was built was 7 months ago. There’s probably some room for improvement here to either have somewhere that lists the currently up to date images or to push a final image that prints a deprecation notice (or something like that to warn the user the image is no longer is updated).
thanks @patricoferris ,
having a deprecation notice would be great
I retried with:
FROM ocaml/opam:fedora-34-ocaml-4.12
but even after running:
[opam@6f5460fd8add web]$ opam update
<><> Updating package repositories ><><><><><><><><><><><><><><><><><><><><><><>
[default] no changes from file:///home/opam/opam-repository
the last versions of some packages are missing, for example duration has 0.1.3 as last version:
[opam@6f5460fd8add web]$ opam show duration
<><> duration: information on all versions ><><><><><><><><><><><><><><><><><><>
name duration
all-versions 0.1.0 0.1.1 0.1.2 0.1.3
Yep, in the output of your opam update command you can see it is pointing to file:///home/opam/opam-repository – the base images have the opam repository cloned into them at the time they are built (they are built weekly, so in less than 7 days duration.0.2.0 will be available in the latest image). See this conversation for why the default repo is not opam.ocaml.orgMake opam.ocaml.org the default repo · Issue #99 · ocurrent/docker-base-images · GitHub (unfortunately I don’t think any of the suggestions at the end have been done yet).
In the meantime you can set the opam repository to point to opam.ocaml.org with:
opam repository set-url default "https://opam.ocaml.org"
opam update # Not sure this bit is strictly necessary
We use ocaml-layer, which I made about a year ago to save us time in CI. It runs a weekly job that builds and publishes a fresh Docker image with everything we want in it. Thanks to this, our CI jobs are fast as the only need to build our own software and none of the external dependencies.
Also available at Docker Hub (ocamlpro/ocaml)
These attempt to be minimal, with the latest opam, and a straight-forward Dockerfile to easily know what’s inside or not. They are updated every week to avoid the need for opam update (but work with it too if you use a fixed tag).
Out of curiosity, why is that Dockerfile compiling and installing both OCaml and opam? If we have opam, can’t we just set up an OCaml switch from there?
I’ll answer in the case of ocamlpro/ocaml: for speed and energy efficiency, since it saves you a recompilation of OCaml at every run, even if you don’t use any extra caching.
Basically, assuming you want OCaml 4.12 and use the corresponding image, you can run opam switch create . ocaml-system instead of just opam switch create ., and thus ensure that the new switch will be created using the local pre-compiled OCaml.
This really makes sense since for most small projects, the compilation time of OCaml is an order or magnitude longer than the project build itself, even including dependencies; but I agree that in some cases (like wanting a specific variant / compiler patch) having a lighter image with no version of OCaml at all would make sense. You can still pick a random version and just not use the system compiler for these cases though.
@mudrz The Docker Hub images have been updated to be more descriptive. The images are still primary intended for use in OCaml’s Continuous Testing systems, and can be a little quirky to use as development images.
A more developer oriented set of images could be quite useful.
