Potential podman-based adjustment to the docker command

[Trevoke]

So, I released org-gtd 3.0 and dropped support for emacs 27.1 because I couldn't run tests on it locally (silex doesn't have a 27.1 tag). I opened an issue about it for silex, but then I wondered how much of this could be done with ... fewer dependencies.

So I went and looked at the Github Actions I use for CI. Long story short, here's a first pass:

1. A Containerfile
2. A command to build an image with a given version of emacs in it
3. Running the tests in a container made from that particular image

Containerfile

Do note the use of emacs_version provided as a CLI arg.

FROM nixos/nix:latest

# Install Cachix.
RUN nix-env -iA nixpkgs.cachix

# Set the Cachix cache name.
ENV CACHIX_NAME mycache

# Use Cachix.
RUN cachix use $CACHIX_NAME

ARG emacs_version

# Install emacs
RUN nix-env -iA emacs-$emacs_version -f https://github.com/purcell/nix-emacs-ci/archive/master.tar.gz

# Set the working directory.
WORKDIR /app

Building the image

Here we pass emacs_version and we give the image a custom name -- stag-27-2, but could be eldev-27-2.

Using podman means the image remains local and docker does not do any funny business.

We use . for current directory, this is run in the root directory of the project, but you can tell from the Containerfile that doesn't matter.

podman build -t stag-27-2 -f Containerfile --build-arg emacs_version=27-2 .

Running the tests

Unsurprisingly, looks like this, reusing the name of the image provided above:

eldev -dt docker "localhost/stag-27-2" -C -dt test

---

So there's clearly some automation work required if we're going to make this happen more reliably, and it's also possible that we can make smaller images.

I'm not sure how I would integrate any of this into eldev functionality, though, but I am sharing it here in case it's of any help :)

[doublep]

I don't really want to manage Docker images. I don't know much about this and I suppose @Silex had his share of problems to solve with the images and reasons to drop non-final versions. Ideally, I'd prefer you to work this out with him. Eldev just builds image name from Emacs version in function eldev--docker-determine-img, so if more images appear, they are sort of "picked up" automatically and there is nothing to do for me here (which is nice).

On the other hand, if you create or find another provider of Emacs Docker images that in some sense better (provides more Emacs versions? supports X? — I also miss ability to test locally with GUI and an older Emacs version), I'm willing to replace the "default" provider that Eldev uses. Currently it defaults to Silex's images because those are the best I know of, but it's not a decision carved in stone.

Also note that ability to use arbitrary images instead of just Emacs version is officially supported and this is not going away. You can just continue using commands like eldev -dt docker "localhost/stag-27-2" ... and that is absolutely fine.

By the way, would be nice if you replied in issue #85. I certainly fixed some bugs that might be related — but they also might be not, and I'd like to know. Now with 1.4 out this should be fairly easy to test.

[Trevoke]

Hmm, this is an interesting point, I wouldn't think of it as you maintaining/managing the docker images, since they are primarily a conduit to the https://github.com/purcell/nix-emacs-ci/ package, but I suppose it does mean people will start asking you questions about them.

What I was trying to do was offer another provider of emacs docker images... Without using docker.

[doublep]

Ah, I didn't realize your goal was to exclude remote-provided images from the equation completely (do I get it correctly now?). I have never used podman. How does it compare to docker? Does your proposed improvement depend on podman or can it be used with docker too? If we were to incorporate this into Eldev, would this mean a container file per Emacs version or not?

[Trevoke]

For me, this is a way to fix the problem I have where I depend on someone else providing the images, when they can be built locally -- in practice, I can't support emacs 27.1 if the image is not there, which is a weird artificial problem.

I had a very strange issue with docker, which might be due to me just not understanding how docker works at all, but it seemed like the containers I built with docker weren't... easily accessible locally, somehow? At least from my usage of docker from years ago, it was a very unpleasant experience of "I built it, why is it not here".

Podman is basically a docker clone that doesn't try to take over nearly as much of the system as docker does. So I'm able to just build a container and then have it there, locally, for me to use. I think podman is also F/OSS ( https://podman.io/ ) which seems like a nicer choice for emacs overall, but ... I also claim ignorance on the finer details.

To answer your questions:

How does it compare to docker? => Apparently docker / podman has a mostly 1:1 API but it's F/OSS.

Does your proposed improvement depend on podman or can it be used with docker too? => It may be usable with docker, if you can build local images with docker, or if you pay for docker and your images can get uploaded there and then reused later, or .. however docker does things nowadays

If we were to incorporate this into Eldev, would this mean a container file per Emacs version or not? => It would be just the one container file, which just requires you to plug in the version of emacs you want and it'll build an image with that version of emacs you can then use as a target to run tests, code, etc.

From the docs:

Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images. Podman provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine. Most users can simply alias Docker to Podman (alias docker=podman) without any problems. Similar to other common Container Engines (Docker, CRI-O, containerd), Podman relies on an OCI compliant Container Runtime (runc, crun, runv, etc) to interface with the operating system and create the running containers. This makes the running containers created by Podman nearly indistinguishable from those created by any other common container engine.

[Trevoke]

FWIW, Silex restored the 27.1 tag.

[doublep]

If you are still interested in this, I guess we can try it out. Note, however, that I know nothing about Podman.

I tried the instructions from your original post, but it failed immediately (I just installed Podman Debian package and have not altered anything in its configuration):

STEP 1/7: FROM nixos/nix:latest
Error: creating build container: short-name "nixos/nix:latest" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

In a sense it might be good if we walk through all the hoops from the start, because then I'd better understand how it could fail on a user machine too.