Add support for Podman runtime about tork HOT 7 OPEN

After further investigation, it looks like a CLI wrapper would be the simplest implementation. Although podman creates lightweight VMs on MacOS and Windows and establishes an SSH tunnel to the VM to access the socket, it requires parsing a configuration file and setting up the tunnel for these platforms.

So, yeah, a CLI wrapper it is for now 😄

from tork.

This is great to know!

from tork.

@runabol would it be okay if you assign this issue to me?

from tork.

Done

from tork.

Hey @runabol,

While investigating the initial implementation, I encountered an issue. The current Podman package for Go, libpod, has dependencies on many types that Podman uses internally (see: containers/podman#12548).

A possible workaround could involve setting some build flags, as mentioned in that issue. However, I believe a better approach would be to utilize Podman's REST API, which is exposed through a Unix socket or a normal socket, similar to Docker. This would also help avoid adding approximately 40MB of dependencies to the project.

What are your thoughts on this?

from tork.

I definitely would agree that adding the library and its attendant dependencies is probably not a great idea.

As for using the REST API through a unix socket, that doesn't sound very cross-platform friendly.

One of my favorite features about podman is its ability to run daemon-less. So if we resort to running it as a service, I feel like we're losing on that advantage. Plus I'm not sure if there's parity between the REST API and the CLI.

What about simply calling the podman cli from Go?

from tork.

I found this issue trying to see whether I could use tork via podman on arch and thought it worth adding this note for anyone who comes after me, whose situation is similar to mine.

If you're happy to run podman with a daemon (which on systemd in my distro is accomplished with systemctl start podman.socket) then just setting DOCKER_HOST to the relevant socket is enough.

from tork.