Managing dependencies in Go might not be the first thing you’d be paying attention to but there comes the time when you likely have to face the task. In this post I’ll share some observations with my first steps using Go from a project maintainer perspective. dep Go dependency management, or as we Gophers say, has a rather longish and slightly complicated . With Go the community now seems to slowly (?) but surely converge on a standard. Since I it anyway in one of the projects I contribute to I thought it makes sense to get some hands-on knowledge under my belt, in a sandboxed environment, before I apply it ‘for real’. vendoring history dep need OK, let’s jump right into it: first, we have to install Go which assumes a more recent version of Go installed (I’m using 1.8): dep, $ go get -u github.com/golang/dep/cmd/dep Next, we’ll need a we want to vendor, so here’s a simple using amongst other things the to create a primitive version of a cluster shell (side note I’m using to set up and run ): program example Kubernetes Go client Minishift Kubernetes The goal is to vendor the packages imported in line 7 to 10. So, in order to do this, I executed in the directory where the file is located these commands: main.go $ dep init$ dep ensure k8s.io/client-go@^2.0.0$ dep ensure github.com/chzyer/readline@1.4 Note that the last two lines are not strictly required, since is smart enough to figure out the versions needed itself. In my case I needed to pin the package to the version to make sure it works against the Kubernetes version I’m using. dep client-go 2.0.0 After that step, the directory layout looks like in the following: .├── Gopkg.lock├── Gopkg.toml├── main.go└── vendor├── cloud.google.com├── github.com├── golang.org├── google.golang.org├── gopkg.in└── k8s.io Now I’m in the position to or the program and execute it. On important note and a potential pitfall at this point: unless you actually import a certain package in your source code, a won’t actually download the version into the sub-directory. go build go install dep ensure vendor/ Coming back to the initial question: what do I need to do now as a project maintainer to make this vendored setup available in a repo for others to use? Since I wasn’t able to find best practices around this topic, I jumped on the channel in the community and the friendly people (special kudos to ) provided guidance: #vendor Go Slack Peter Bourgon In your repo you should at least include and . Gopkg.toml Gopkg.lock You can include the subdirectory, and … vendor/ … if you include the subdirectory: vendor/ your repo gets bigger :( pull request diffs can get more complicated to deal with :( guarantees reproducible builds as it decouples you from upstream changes :) it doesn’t require the user of your repo to execute an additional in order to be able to build the program :) dep ensure Summing up: while Go is still early days and lacks some documentation around best practices (apparently a is coming soon) I found it simple to use and feel like I’m ready to use it in anger now. dep FAQ EDIT: As pointed out by , you can generate visualizations of dependency graphs for packages via godoc.org, for example, Ahmet Alp Balkan https://godoc.org/github.com/mhausenblas/cinf?import-graph&hide=1
