Which ocaml versions to ultimately provide in docker-coq?

[erikmd]

This meta-issue is a follow-up of this Zulp discussion (login required, but excerpts pasted below).

Also, it is somewhat related to coq/coq#12757 (in particular, the comments below assume coq/coq#12757 has been implemented, thereby providing a new dummy package coq-native) and it is less urgent than finalizing #7

Zulip excerpts

@erikmd:

providing three different versions of OCaml in coqorg/coq was just a compromise to have:

• the minimal working version of OCaml (4.05.0)
• the version recommended by @ejgallego in https://coq.discourse.group/t/install-notes-on-coq-and-ocaml-versions-configuration/713 (4.07.1+flambda) → so without native_compiler
• a more recent version of OCaml than 4.07.1 as requested by users, cf. e.g. @liyishuai 's comment feat: Bump COMPILER_EDGE to 4.09.0+flambda docker-base#5 (comment), given that 4.07.1 is not the "edge" version anymore… and 4.09.1+flambda has been proposed to this aim (but anyway, with docker-keeper it is now very easy to add more tags synonyms in coqorg/base and coqorg/coq, so we could consider having coqorg/coq:8.11-ocaml-4.10-flambda as well for example!) → without native_compiler as well

so if we want to have coq-native installed in at least one flavor of the images, there is not many possibilities, hence my proposal to add it later on in 4.05.0 :)

@palmskog:

Ocaml 4.05.0 is now more than 3 years old and to me a terrible release compared to 4.07.1. Will we ever get rid of it?

@erikmd:

Sure, it may be possible to put forward 4.07.1+flambda as the default ocaml version within docker-coq… (say, when flambda support will be fully enabled :)
[…]
BTW note that the current semantics of the ocaml_version field of docker-coq-action provides three values: minimal, 4.07-flambda, 4.09-flambda;
I don't know what's @Zimmi48 opinion but I'm unsure it would be very convenient to "drop" minimal (at least for the backward compatibility of the projects' CI that use that value minimal).
However as I mentioned in my previous comment, I'd rather propose to just promote 4.07-flambda as the default version soon: this would thus be in line with Emilio's Discourse post about recommending OCaml 4.07.1+flambda… while keeping one or two more OCaml versions, for users who really wants a more recent (or not!) version :)

Currently, given the new infrastructure to build the images, it is much easier than before to maintain 3+ different flavors of the images with different compilers etc.

So the goal of this issue is to discuss what'd be the best choices for the ocaml versions to put forth in docker-coq / docker-coq-action, and with which options (i.e. Coq's native-compiler, +flambda…).

My current position is that:

• we could change the "default version" to 4.07.1+flambda soon (instead of getting 4.05.0), without coq-native (by "default version" I mean that we should get that (single-switch) config if we do docker pull coqorg/coq:8.12)

• also, another switch with the most recent supported version of ocaml could be made avaiable for each Coq version (not necessarily 4.09.1+flambda, but e.g. 4.10 or 4.10+flambda when using Coq 8.11.1+) for users that specifically need a recent ocaml besides coq.

if you agree with the two points above, several questions arise though:

• should we remove 4.05.0 from docker-coq soon? (even if it is still the minimal supported version of ocaml by coq.dev, and it is also one of the versions tested by opam-coq-archive's CI)

• which switch / images should be added with some coq-native support? maybe a 4.07.1 regular switch (without flambda)?

• what should be the new values of docker-coq-action's ocaml_version? (maybe 4.07-native, 4.07-flambda, edge if minimal is removed?)

Opinions on that?

(Cc @Zimmi48 @ejgallego @SkySkimmer @palmskog @clarus @Blaisorblade @liyishuai @anton-trunov @tchajed @JasonGross @CohenCyril @silene @proux01 FYI)

[erikmd]

To follow-up my previous post and that of coq/coq#12757 (comment), regarding docker-coq-action's ocaml_version setting:
I guess in a first stage (as soon as ocaml/opam-repository#16887 is addressed), it should be fine to be as backward-compatible as possible, namely:

• keep 4.07-flambda, 4.09-flambda, and minimal = 4.05 for now;
• also add 4.07 (based on ocaml-base-compiler.4.07.1)
• and enable coq-native in both non-flambda switches (4.05, 4.07)

so that docker-coq-action-based CI configuration of existing projects could be kept as is (the only breaking change would be that coq-native is not installed in 4.09-flambda)

@Zimmi48 does this look good to you regarding docker-coq-action?

[erikmd]

Finally and manually speaking (using CLI), users could still fetch single-switch docker-coq images by doing:
docker pull coqorg/coq:8.12-ocaml-4.09-flambda
but the question is, after the migration, what should be the "default ocaml version" of coqorg/coq:8.12 (without -ocaml-* prefix)?

maybe:

1. coqorg/coq:8.12 = coqorg/coq:8.12-ocaml-4.07 (with the coq-native package flag);
2. or coqorg/coq:8.12 = coqorg/coq:8.12-ocaml-4.07-flambda (without native_compute support)?

I'd tend to say 1., but feel free to react if you disagree!

[palmskog]

For some extra context, I think one of the main arguments for dropping 4.05.0 support is the parallel make compilation bug for Coq plugins (or any combined Coq+OCaml projects) that we have tried to squash for a long time in the Coq opam repository. This bug is completely gone in 4.07.1. More on this can be seen in, e.g., coq/opam#1346 (comment).

[Zimmi48]

Wouldn't changing the default version be sufficient to achieve this? It seems a bit weird to drop support for minimal. What if plugin developers want to support exactly the same range of OCaml versions as Coq (for obvious reasons of not constraining their users further) and want to test that this is the case in CI?

[Blaisorblade]

Good point @Zimmi48.

To address @palmskog's point, maybe Coq should consider dropping or deprecating support for the offending OCaml versions, subject to the appropriate guidelines (whatever they are).

Then docker-coq's policy would default to a "recommended" OCaml version and also offer the minimal and maximal OCaml versions for use by CI of plugins.
However, that assumes that testing on OCaml 4.05 and 4.10 is enough to support intermediate versions, which isn't 100% true (we know it's not true for Coq in corner cases). Is that true enough for plugins?

[palmskog]

To be clear, as much grief as 4.05.0 has caused, I don't mind if there is a switch with 4.05.0 in the Coq Docker images as long as it's not the default switch, i.e., it's not the default OCaml version you get. Indeed, some unlucky plugin developers may require 4.05.0 for some reason.

Also, if Docker images become single switch, please don't make 4.05.0 the default OCaml you get when requesting a Coq docker image. Force people to request an image with 4.05.0 manually.

[Zimmi48]

@Blaisorblade Have we ever been hit by this problem of testing only the bounds?

We've adopted 4.05 as this is what is available in Debian stable today. We could relax this constraint but I believe that Emilio wanted to bump to 4.08 directly at some point but 4.08 is problematic for other reasons.

[Blaisorblade]

We've adopted 4.05 as this is what is available in Debian stable today.

Supporting Debian stable is an excellent argument — just not for making this a default.

@Blaisorblade Have we ever been hit by this problem of testing only the bounds?

I was only thinking of Coq itself, for flambda/native-related issues. No clue on plugins, so I was turning that question to you people — it seems unlikely, but I figured I should ask anyway because of Murphy's law 😅

[ejgallego]

My point of view here is that it doesn't make a lot of sense to bump the minimal OCaml version unless we need some features from newer OCaml. This was the case in the past [we really wanted 4.02.3 and 4.05], but for now, no pressing need seems to be around.

[erikmd]

Hi all, we have just discussed further this topic with @Zimmi48, and we agreed on the following plan, with the aim to keep backward-compatibility as much as possible, answer the needs to have ocaml 4.10 for 8.12.0 (cf. this request on Zulip), while limiting the number of ocaml versions prebuilt for each version of Coq:

• First, I'll finalize this week the "single-switch" PR feat: Switch to single-switch images #7 by incorporating a transition period where current images (e.g., the dual-switch coqorg/coq:8.12 with ocaml-(4.05.0, 4.07.1-flambda), and the single-switch coqorg/coq:8.12-ocaml-4.09-flambda) are kept as is, then after this transition we should use e.g. coqorg/coq:8.12-ocaml-4.05 (or another tag to be listed in https://hub.docker.com/r/coqorg/coq#supported-tags).
• Each Coq version will be prebuilt with:
  • the minimal version of ocaml,
  • 4.07.1+flambda, which has been widely tested up to now and is compatible with each Coq since 8.7,
  • the last two compatible ocaml versions (namely for coq 8.12.0: ocaml 4.10 and 4.11).
• Regarding the limitation of the number of supported ocaml versions: docker-coq will track the last two compatible versions of ocaml for each coq version, so the antepenultimate compatible ocaml won't be available anymore if a new ocaml is released and compatible with this coq version.
• Regarding the impact of users of https://github.com/coq-community/docker-coq-action, as the action acts as a facade, the migration to single-switch will be transparent for the users (while leading to a reduction of the images size and download time).
• Ideally, we plan to announce these changes at the same time mathcomp/mathcomp-dev:coq-dev infrastructure will be updated (to be automatically rebuilt after coq@master, instead of waiting for a nightly build)

[ejgallego]

Sounds very good, IMHO not a lot of value providing 4.08/4.09 indeed. Those with special needs can always build their own docker images, maybe worth adding a small section on how to do this?

[erikmd]

Those with special needs can always build their own docker images, maybe worth adding a small section on how to do this?

Indeed, why not!

just to recap the two ways to do this:

• one can either manually build other versions by reusing the docker-base and docker-coq Dockerfiles, passing the proper --build-arg options;
• or more easily/automatically, rely on the docker-keeper tool to build/push one's own images (containing coq and other libs if need be).

[erikmd]

Closed as addressed by PR #7

I will post a related announce on Discourse to recap the main changes (which are backward-compat. during the migration phase).