Giters

coq-community / docker-coq

Docker images of the Coq proof assistant (see also: https://github.com/coq-community/docker-coq-action) [maintainers=@erikmd,@himito]

Home Page:https://hub.docker.com/r/coqorg/coq/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Coq recompilation messes up binary dependencies

cmester0 opened this issue · comments

commented

I am using the coqorg/coq:8.13.2-ocaml-4.05.0 container to compile Coq .v in combination with .vo files, however since Coq just got recompiled

The Coq Proof Assistant, version 8.13.2 (September 2021)
compiled on Sep 27 2021 23:16:43 with OCaml 4.05.0

which previously was

The Coq Proof Assistant, version 8.13.2 (September 2021)
compiled on Sep 12 2021 11:24:01 with OCaml 4.05.0

I now have to recompile all the binaries to match this version. Is there a stable docker image where Coq is not updated? And is this the intended behavior? I was hoping to that fixing the version of both coq and ocaml would fix this.

commented

If you need to compile Coq yourself, why do you use the docker-coq image as opposed to the docker-base image (https://github.com/coq-community/docker-base/ / https://hub.docker.com/r/coqorg/base#supported-tags)?

That being said, these images will still be updated once in a while to update things like the base Debian image itself.

What is your use case exactly?

commented

We are using the software foundations book, so we do not want to distribute the solution files to students for previous weeks. The files are used by Github CI to test whether handins are completed correctly, so only dependencies are binary files, while the current handin files are .v files.

commented

OK, I had misunderstood what you said in your initial report (I thought you needed to compile Coq, but that's not the case).

Where do you store the precompiled vo files? In a GitHub Actions cache? Are you sure that you actually need to recompile them? What happens if you don't?

commented

I store them in a subdirectory in the students repositories (the folder is .github/vo_files_for_CI). When I do not recompile I get errors of the following structure.

Compiled library LF.Maps (in file /__w/lf-2021-assignment-6/lf-2021-assignment-6/.github/vo_for_CI/Maps.vo) makes inconsistent assumptions over library Coq.Init.Ltac

Recompilation fixes these issues.

commented

OK. That won't help with your issue, but I'm curious to understand why that's the case that we get this error message even if the versions of Coq and OCaml are the same. Summoning @ppedrot.

To solve your problem, the only solution that I see and that I can recommend is to push the current version of the Docker-Coq image that you are using to a personal docker registry. GitHub provides one: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
This will give you full control over when you update your copy of the Docker image.

commented

It happens that vo files depend on the hash of OCaml plugins they link to, so I'd look there first. I think that the build of OCaml object files is not reproducible by default, you need to pass some options for that.

commented

Hi all,
thanks @Zimmi48 and @ppedrot for your comments!
Just to elaborate on @cmester0's question:

is this the intended behavior?

the intended behavior is indeed to recompile on a regular basis all Docker-Coq images:

  1. either when adding some opam packages (see e.g. PR #31)
  2. or to benefit from an opam binary or OS-level upgrade (given a Docker image is a snapshot of an OS, not a mere git tag)
  3. and sometimes it is utterly necessary to rebuild them, otherwise the precompilation would become useless (see e.g.
    this Zulip thread for context)

Anyway, if you are not facing the situation No. 3. above, the workaround by @Zimmi48 to "push the current version of the Docker-Coq image that you are using to a personal docker registry" can work to some extent indeed.