Make opam.ocaml.org the default repo

[dra27]

As noted in #98 (comment), the switches created in the base images have ~/opam-repository as the default remote, so opam update does nothing, which is a bit surprising for new users to the container images.

Any change here will necessarily impact existing users of the images (ocaml-ci, opam-repo-ci, etc.). If we do this, let's do it once (the clever part of this idea is due to @talex5!):

• At the end of the build, change the URL for the default remote to https://opam.ocaml.org
• Require existing users to change their Dockerfiles, but introduce a script opam-update-repo-to which takes a commit and whose job is to update the switch to that commit of opam-repository so that this change only has to be done once
• opam update will then always retrieve https://opam.ocaml.org

Masking the use of ~/opam-repository behind a script will also allow future optimisations such as making it a bare repo without breaking images again.

[dra27]

Examples at present:

https://github.com/mirage/mirage-www/blob/master/Dockerfile#L2:

cd ~/opam-repository && git pull origin master && git reset --hard sha && opam update

https://github.com/ocurrent/ocaml-ci/blob/3e0bea90512456d2f97accafb221b496bbe9128b/lib/opam_build.ml#L83-L86:

cd ~/opam-repository && (git cat-file -e sha || git fetch origin master) && \
       git reset -q --hard sha && git log --no-decorate -n1 --oneline \
       && opam update -u

all would become ~/opam-update-repo-to sha.

[hannesm]

I just run into this, and wanted to report that the current "ocaml/opam" docker images are very hard to use - especially for people that are not used to the opam workflow. They have an old version of a git clone of the opam-repository in /home/opam/opam-repository, and the opam is configured in a way that opam update does not result in updating the opam repository from opam.ocaml.org (which would be the expectation).

[dra27]

Just double-checking: "old" should be no more than a week?

[hannesm]

I don't know exactly. It was in a state where an opam update was required (FROM ocaml/opam:debian-10-ocaml-4.11) since git-mirage 3.3.1 was unknown.

[dra27]

CI dev meeting notes on this. Feeling is that the image should remain as targeting CI primarily, and so the default workflow should be for good Docker hygiene - i.e. focus on reproducibility. In this aspect, opam update is of course bad. So the solution we propose is to turn this idea on its head:

• The utility script opam-update-repo-to is a good idea regardless
• Similarly, a utility script to switch to opam.ocaml.org and helps the alternate use-case where it's wanted
• Finally, a little ENTRYPOINT / CMD manipulation should allow a motd/welcome for direct use of the to advertise these facts (as will updating the readme information on Docker hub, which is also in hand)

So the existing behaviour remains, but the images advertise that more obviously and provide assistance to go from the CI workflow to the more usual opam one.