moby: Setting Ports in a container config no longer compiles
Setting Ports in a container config no longer compiles
package main
import (
containertypes "github.com/docker/docker/api/types/container"
"github.com/docker/go-connections/nat"
)
func main() {
exposedPorts := map[nat.Port]struct{}{"514/udp": {}}
containerConfig := &containertypes.Config{
ExposedPorts: exposedPorts,
}
}
monitor.go:11: cannot use exposedPorts (type map[“github.com/docker/go-connections/nat”.Port]struct {}) as type map[“github.com/docker/docker/vendor/github.com/docker/go-connections/nat”.Port]struct {} in field value
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 20
- Comments: 46 (18 by maintainers)
Hello guys. I was able to solve this problem by deleting the folder: <your Libraries>/src/github.com/docker/docker/vendor/github.com/docker/go-connections
And you need to install github.com/pkg/errors.git
Have a happy new year
Is there a good way to fix this if you aren’t using glide?
You just need to remove the nested vendor dir then it will work
rm -rf vendor/github.com/docker/docker/vendor
On Mon, Jan 23, 2017 at 2:38 PM Isaac (Ike) Arias notifications@github.com wrote:
It was never doing this before we used to have
vendor/src/github.com...just fwiw (which is anti-go), we are releasing our prototype dep management tool either later today or tomorrow and it should address this issue (it flattens all deps so there is no nested vendor to consider)@cpuguy83 Unfortunately stripping the vendor directory breaks other things. 😦
I’m of the impression that libraries aren’t supposed to have a
vendordirectory in the first place?So, what if I don’t use vendoring? How would I fix this issue?
looks like there is a
strip-vendorflag you can useOn Mon, Jan 23, 2017 at 2:52 PM Isaac (Ike) Arias notifications@github.com wrote:
I guess this would be fine if this code was not intended to be used outside of this repo. But if the client sub-package is intended to be used by other Go projects as a client library (my assumption) then this is currently a blocker.
It’s obvious that any type that a public API depends on should be accessible to the consumer as well. I will try @soyking’s suggestion for now. For the time being, any third-party Go projects that depend on the latest version of Docker client code that uses the “nat” package cannot be built.
temporary solution:
you could use go vendor tools such as godep govendor to save the dependency to current project, and then both
dockerand your code will pointer to the same package in vendor directory.I fail to see the benefit of using vendor directories in go projects. I’d sooner say the bug is with the decision to use a vendor directory, considering the way go is wired. why wouldn’t you just change your go root for a project, sort of like venv in python? go has a built-in package management solution, and while there might be virtues in using “userspace” package management solutions, those solutions shouldn’t openly conflict with the default go ecosystem.
that said,
glide init && glide install -vdid the trickI ran
rm -rf $GOPATH/src/github.com/mob/moby/vendor. I eventually got it working by moving todepand hacking on it, but it wasn’t trivial. It seems like a bug that I have to stripvendorin the first place. I’ve never had to do that with another Go library, and as I mentioned above, I’m under the impression that libraries shouldn’t havevendordirectories? Maybe the bug is with Go’s tooling?Same issue, I don’t want to use glide, https://github.com/golang/dep is better
I’m also faced with this problem. I’m building a library using these imports and can’t have a vendor folder in the library.
I think we need to copy the api code into a separate repo periodically, and at least certainly at release. It will still be painful to use since you’ll have to rewrite imports, though.
Any suggestions for this situation ?
I can’t use APIs normally…