moby: Unable to use some of the docker API due to vendoring issues

Description

I am trying to use version 1.13.0-rc3 of the docker api for golang. My imports are:

"github.com/docker/docker/api/types"
"github.com/docker/docker/api/types/container"
"github.com/docker/docker/api/types/network"
"github.com/docker/go-connections/nat"
"github.com/docker/go-units"

I am unable to create a HostConfig like:

portBindings := make(nat.PortMap)
var ulimits []*units.Ulimit
hostConfig := &container.HostConfig{
		PortBindings: portBindings,
		Resources: container.Resources{
			Ulimits: ulimits,
		},
	}

Due to the errors:

cannot use portBindings (type "github.com/docker/go-connections/nat".PortMap) as type "github.com/docker/docker/vendor/github.com/docker/go-connections/nat".PortMap in field value

cannot use ulimits (type []*"github.com/docker/go-units".Ulimit) as type []*"github.com/docker/docker/vendor/github.com/docker/go-units".Ulimit in field value

I cannot use the vendored versions, so how can I get around this?

Steps to reproduce the issue:

Try to create a container.HostConfig using github.com/docker/go-connections/nat.PortMap or github.com/docker/go-units.Ulimit

Describe the results you received: Failed to compile

Describe the results you expected: Compile

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 27
Comments: 15 (4 by maintainers)

Most upvoted comments

Well then… wow.

ds0nt on Jan 12, 2017

I think I worked around my issues for now, by going:

cd GOPATH/src/github.com/docker
rm -rf docker/vendor
rm -rf cli/vendor
rm -rf distribution/vendor

And then ensured my version of cobra/spf13 + cobra/pflag were up to date. Not elegant, but technically works around my issues.

CpuID on Jul 20, 2018

Just wanted to chime in here, several years later, that this is still a recurring and prevalent issue. My existing workaround was deleting the vendor folder, but this is entirely impractical and absurd. Currently trying to solve the issue with go deps. Life is pain.

zscole on Jan 31, 2019

@tamird I do agree it’s not the best. It’s just the current workaround, and I really wish we could somehow make it work. Having a vendor folder is a huge enhancement on the development on docker/docker itself as we don’t rely on some autopath hack anymore but it broke users of the client side.

Still looking at some possible ideas like extracting the client client.APIClient to a repository for each tagged version of docker (i.e. any RC and GA releases) or something else.

vdemeester on Dec 13, 2016

@SweeXordious You can take a look at this comment from @thaJeztah, he explains what procedure should be followed to get it work with go mod 😉

akerouanton on Jul 26, 2020

This rationale is beyond absurd. The API client was previously in a separate repository (https://github.com/docker/engine-api) but it was deprecated and folded into docker/docker, leaving us (your users) with no choice but to depend on docker/dcoker.

On Tue, Dec 13, 2016 at 11:05 AM, Vincent Demeester < notifications@github.com> wrote:

Quoting @dnephin https://github.com/dnephin on this as I do agree with him.

If you’re using docker/docker as a dependency to your project you should manage your dependencies using a tool like vndr or glide. You shouldn’t rely on the vendor/ directory in this project.

The workaround is to remove the vendor/ folder of the docker/docker after getting it. It’s a little bit tricky depending on what you are using to manage your dependencies though.

And as @tiborvass https://github.com/tiborvass said

Hopefully we’ll find a solution as part of the ongoing works in the Go world.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/docker/docker/issues/29362#issuecomment-266779362, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdsPAR2IsaDo-LqVMPQsQUoINvSqySIks5rHsJLgaJpZM4LLttn .

tamird on Dec 13, 2016