Default git credentials setup

[sim642]

The Dockerfiles and images generated with this for the ocaml/opam images set up default git credentials:
https://github.com/avsm/ocaml-dockerfile/blob/f184554282a3836bf3f1c34d20e77d0530f8349d/src-opam/dockerfile_linux.ml#L24-L28
Why is this done/desirable?

This creates /home/opam/.gitconfig, which prevents the ocaml/opam images from being used out-of-the-box as devcontainers, because apparently the presence of this file prevents the automatic use of outside git credentials: https://code.visualstudio.com/docs/remote/containers#_sharing-git-credentials-with-your-container.
Thus as a devcontainer base image, inside the container you'd be accidentally committing everything as Docker <docker@example.com> without realizing that the usual mechanism of it using outside git credentials hasn't worked. Then one has to rewrite git history to fix the author information of such commits.
Moreover, even without using as part as devcontainer, but for other purposes of doing git commits inside such containers will use those default credentials instead of giving the usual prompt of asking the user to set them up, because they've already been set up by the base image.

Currently I have to work around this by using RUN rm ~/.gitconfig as an extra step on top of these base images. It isn't much, but I fail to see why I'd ever want to commit as some weird default user I haven't explicitly set up myself.

[dra27]

The ocaml/opam images on Docker Hub are primarily intended to support CI systems (in particular, opam-repo-ci for ocaml/opam-repository and the ocaml-ci GitHub App). opam, when using Git remotes, expects git to have been configured and opam-repo-ci in particular generates merge commits - git-commit doesn't work if you haven't specified user.email and user.name.

We may have a look in the coming months at tweaking these images to be slightly more appropriate for general use (at least the "generic" ocaml/opam images)

[avsm]

I'd prefer to just generate an explicit devcontainer image rather than try to squeeze the CI images and the devcontainers images together. @sim62 -- do you have anything else you need in the devcontainer image aside from the git setup?

[sim642]

There is another annoyance, but I'm not sure if there's any good solution for it because it's kind of cyclic.

When using an image with just opam (without any OCaml version switch) and creating a local switch (e.g. using a lock file) inside the devcontainer, then if VSCode starts and attaches to the container, it won't have the desired environment from eval $(opam env). VSCode's in-container adapter-thingy will start before it can run such command to update the environment in which it should run itself and run all of its processes (integrated terminals, LSP, etc).

In my current attempt I took the output of opam env and hardcoded it into a .env file to pass use with the --env-file Docker argument. It's kind of backwards because even on the first run, that hardcoded initial environment already has the paths that the local opam switch is intended to be created.
(Also, I couldn't find anything about doing a similar environment activation with e.g. Python's venv or conda for devcontainers. Maybe the intent is simply that the devcontainer itself is isolated enough that such local switches shouldn't be necessary and polluting a global one is fine.)

I can't say this is the fault of the opam Docker images, but rather the VSCode devcontainer system (if there even is anything that could be done differently on that side). But overall, this somewhat reduces the usefulness and convenience of having a devcontainer which comes perfectly set up for development.

[avsm]

@sim642 I've been adding a 'devcontainer OCaml feature' which composes with the upstream VSCode features. You can find one use of this in https://github.com/realworldocaml/book/blob/master/.devcontainer/devcontainer.json and the associated feature Debs are created in https://github.com/avsm/ocaml-devcontainers

I'll move to close this issue once I publish a post on how to use the VSCode devcontainers feature properly. It's currently being "stress tested" by a number of my undergraduate students.