[question] Why podman via shell over Go API?

[vsoch]

Hi! This isn't a bug or an issue, but rather just a design question. In the file here you chose to implement interactions with Podman via a shell as opposed to using Go APIs and I was wondering about the rationale behind these choices? I'm starting to spec out using Podman in one of my tools and I saw your decision and it gave me pause about using via Go. Thank you!

[vsoch]

Ah just ran into this when trying to add podman to my Go modules - maybe related to this question?

github.com/mtrmac/gpgme
# github.com/containers/storage/drivers/btrfs
../../../../go/pkg/mod/github.com/containers/storage@v1.37.0/drivers/btrfs/btrfs.go:8:10: fatal error: btrfs/ioctl.h: No such file or directory
    8 | #include <btrfs/ioctl.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.
# github.com/mtrmac/gpgme
../../../../go/pkg/mod/github.com/mtrmac/gpgme@v0.1.2/data.go:4:11: fatal error: gpgme.h: No such file or directory
    4 | // #include <gpgme.h>
      |           ^~~~~~~~~
compilation terminated.
# github.com/containers/image/v5/manifest
../../../../go/pkg/mod/github.com/containers/image/v5@v5.17.0/manifest/oci.go:44:234: undefined: v1.MediaTypeImageLayerNonDistributableZstd
../../../../go/pkg/mod/github.com/containers/image/v5@v5.17.0/manifest/oci.go:44: undefined: v1.MediaTypeImageLayerZstd
../../../../go/pkg/mod/github.com/containers/image/v5@v5.17.0/manifest/oci.go:105:39: undefined: v1.MediaTypeImageLayerNonDistributableZstd
../../../../go/pkg/mod/github.com/containers/image/v5@v5.17.0/manifest/oci.go:110:39: undefined: v1.MediaTypeImageLayerZstd
make: *** [Makefile:14: all] Error 2

[debarshiray]

There is some past discussion on #100

In the very beginning, we did look into using the libpod Go API from Toolbx instead of forking and exec:ing podman(1). However that didn't pan out because:

• There was a concern that mismatches in the libpod version bundled in toolbox(1) and podman(1) would prevent containers from being interoperable with both tools.
• Podman (or libpod) containers set up podman(1) as the exit handler, which means that we won't be entirely insulated from podman(1).

In the past, podman(1) had a Varlink interface to talk to it. However, that wasn't really well-maintained, and eventually got removed. Nowadays there's some other Go-based interface to talk to podman(1).

Unfortunately, the churn in those alternate interfaces coincided with Toolbx being re-written in Go from POSIX shell. So, we didn't want to make our lives complicated by including an immature, work-in-progress interface to the mix.

We are generally happy with using podman(1) directly. It's not ideal because error-handling is always tricky, but the frequency of errors has also gone down over time. One big thing for us is that Toolbx is a relatively low-level component of the OS. On Fedora Silverblue, it's basically the shell that developers use. This means that we need an interface that's simple and tight, and won't change fundamentally over time.

Recently, we introduced Toolbx in RHEL 8.5, and that wouldn't have been possible if we were using a more sophisticated interface. Same applies to all the other OSes (eg., Arch, Ubuntu) where people have been Toolbx.

[debarshiray]

Closing.

Feel free to leave a comment or re-open, if you have further questions. Thanks for stopping by!