ERROR: runtime error: index out of range [0] with length 0

[lunik1]

I get the above runtime error when running aup on the latest unstable NixOS, reproducible with the "minimal" example in this repo. I haven't had time to confirm this, but I suspect it could be connected to the update to podman 5.0.

[roberth]

I have not seen this error before, and it does not look like a Nix, Arion or Haskell error.
Podman previously did not invest in a major update migration (2-3? 3-4? I don't recall.), so I'm not too surprised that something would break. Do you have state from 4.0 on your machine?

[roberth]

The arion tests pass for nixos-unstable, podman 5.0.2.

[lunik1]

I'll dig into it a bit more. Rolling back to a pre-podman 5.0 nixpkgs commit did fix it for me.

[lunik1]

Still not sure what's going on entirely, but I now see this on two systems. The error message looks like it is coming from Go. I have tried a podman system prune and reboot to get clear any old podman state.

Running strace shows what command sets it off

[pid 76385] execve("/nix/store/491k4bspg098nm2jqk9p81hrn4wx5d01-docker-compose-1.29.2/bin/.docker-compose-wrapped", ["/nix/store/491k4bspg098nm2jqk9p8"..., "--file", "./.tmp-arion-docker-compose76199"..., "--project-name", "dionysus", "up"], 0x2225640 /* 31 vars */) = 0
ERROR: runtime error: index out of range [0] with length 0

and indeed running

/nix/store/491k4bspg098nm2jqk9p81hrn4wx5d01-docker-compose-1.29.2/bin/.docker-compose-wrapped --file docker-compose.yaml up

where the docker-compose.yaml is generated by arion show triggers the same error.

[roberth]

Another thing you could try is start with an empty docker compose file and then add things until it fails, or insert half of it and do like a bisect of sorts.

[lunik1]

Even the trivial

version: '3.4'

triggers it. But I have confirmed it is not an arion bug. It seems to be a bug between docker compose v1 and podman v5.0. I only see this error when using docker-compose v1 and from nixpkgs commit f9be31de1b7b5f3738f23a0c04a20bc524cab30c onwards, which introduced podman v5.

I have not seen this reported elsewhere yet, but fyi podman no longer test against docker compose v1, see containers/podman#22421

I'm also fairly certain now that #230 is a docker-compose v1 bug, too.