Clarify external use and support for pkg/bindings

[drewbailey]

/kind feature

Clarify support & usage of pkg/bindings

pkg/bindings seems like current and only go client to interact with the podman http api. It would be reassuring if this package was given a readme and identified as a package that can and should be consumed by external projects similar to docker's go client https://github.com/moby/moby/tree/master/client

I was also wondering if there had been any consideration of turning this into it's own go module to ease external adoption.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[mheon]

@rhatdan @baude @jwhonce We should discuss this one at scrum and decide what to do. I'm not opposed to splitting this out, but we probably want to wait until the libpod move to do it (to avoid having something that vendors containers/podman, and is then vendored into containers/podman...)

[baude]

@drewbailey as @mheon suggested, we did discuss this as a team. the overwhelming response was to keep to the bindings in containers/podman. however, we do agree that adding readme's and other related things are more than appropriate. we have a tutorial coming out here very shortly from a team member on how to consume and use the bindings. from that, we will derive a readme.

i am wondering ... if you guys have started using the bindings, do you want to contribute a readme or anything related?

[drewbailey]

@baude sorry, I should have been more specific. I don't think many users would care if the package lived in containers/podman as a submodule or some other repository. But, in it's current form, I don't think that pkg/bindings is suitable for community use. Since it is currently not isolated from the rest of the podman project, community projects will need to specify the entirety of the podman project as a dependency to use pkg/bindings.

Consider a simple main.go

package main

import (
	"context"

	"github.com/containers/libpod/v2/pkg/bindings"
)

func main() {
	_, err := bindings.GetClient(context.Background())
	if err != nil {
		panic(err)
	}
}

Attempting to fetch the package leads to the following errors which can be resolved by installing a few packages.

λ drew [podman-test] → go get github.com/containers/libpod/v2/pkg/bindings
go: found github.com/containers/libpod/v2/pkg/bindings in github.com/containers/libpod/v2 v2.0.4

# pkg-config --cflags  -- devmapper
Package devmapper was not found in the pkg-config search path.
Perhaps you should add the directory containing `devmapper.pc'
to the PKG_CONFIG_PATH environment variable
No package 'devmapper' found
pkg-config: exit status 1
# 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/storage/drivers/btrfs
../../../go/pkg/mod/github.com/containers/storage@v1.18.2/drivers/btrfs/btrfs.go:8:10: fatal error: btrfs/ioctl.h: No such file or directory
    8 | #include <btrfs/ioctl.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.

The resulting go.mod

module github.com/drewbailey/podman-test

go 1.14

require github.com/containers/libpod/v2 v2.0.4

This alone adds around 34mb to the apps vendor directory.

For now, we will just be writing our own client, but we would definitely be interested in a community go client to interact with the api, much like Docker does with https://github.com/moby/moby/tree/master/client

[rhatdan]

I think it would be better for us to fix this exact behaviour then to break it out. A lot easier for us in the long run.

[mheon]

We probably need to audit the imports of pkg/bindings and figure out what we're dragging in... It could be we're using a random structure out of Kubernetes or CNI and dragging in massive packages from those two as a result.

[vrothberg]

Based on the error it looks like pkg/bindings is importing c/storage and c/image. Those will be pulled wherever the package is, so we need to prune the dependencies and add checks to the CI to prevent them from being pulled back.

[rhatdan]

@baude I think after the bug week, we should work on this. Basically figure out how we can minimize the stuff we pull in for bindings. Something you are pretty good at. :^)

[baude]

@vrothberg lets discuss tomorrow morning. I don't think this appears to be what we speculated... module analysis provided below.

3.6M runtime
1.4M reflect
828K syscall
468K time
424K regexp/syntax
416K internal/reflectlite
400K regexp
400K os
352K image
276K strings
276K strconv
240K internal/poll
228K math
224K unicode
208K bytes
200K encoding/binary
176K bufio
160K sync
144K crypto/cipher
132K io
116K sort
112K math/rand
108K context
104K path/filepath
88K image/color
76K hash/fnv
76K encoding/base64
72K io/ioutil
60K hash/crc32
60K container/list
52K internal/fmtsort
44K math/bits
40K github.com/containers/podman/vendor/golang.org/x/crypto/openpgp/errors
36K internal/cpu
28K unicode/utf8
28K errors
28K crypto
24K sync/atomic
20K runtime/internal/sys
20K internal/bytealg
20K image/internal/imageutil
16K runtime/internal/atomic
16K internal/testlog
16K internal/syscall/unix
16K hash
16K github.com/containers/podman/vendor/github.com/containers/image/v5/pkg/compression/internal
16K crypto/hmac
8.0K internal/race
8.0K crypto/subtle
4.0K vendor/golang.org/x/crypto/internal/subtle
4.0K runtime/internal/math
4.0K internal/syscall/execenv
4.0K internal/oserror
4.0K github.com/containers/podman/vendor/golang.org/x/sys/internal/unsafeheader
4.0K github.com/containers/podman/vendor/github.com/containers/common/version
4.0K crypto/internal/subtle

[vrothberg]

Running ./dependencies/analyses/dependency-tree.sh github.com/containers/podman/v2/pkg/bindings lists a lot more (transitive) dependencies, including containers/storage, image and so on.