A Roadmap to Merging 'dep' into the Go Toolchain

This can&#x27;t happens fast enough.<p>I have been having a fantastic time with Go... Up until the point I have to add a new package to my projects and go through CI and deployment.<p>Glide works mostly OK, but it&#x27;s not the final solution, that&#x27;s for sure. Even big packages on github fail to produce releases, so you have to depend on master branches... One day your builds just decide to break. It&#x27;s a nightmare.

This podcast (iOS) is really worth listening. Straight from the horse&#x27;s mouth:<p>&quot;Dependency Management, Semver, and Community Consensus&quot; <a href="https:&#x2F;&#x2F;itunes.apple.com&#x2F;my&#x2F;podcast&#x2F;go-time&#x2F;id1120964487?mt=2&amp;i=1000382116565" rel="nofollow">https:&#x2F;&#x2F;itunes.apple.com&#x2F;my&#x2F;podcast&#x2F;go-time&#x2F;id1120964487?mt=...</a><p>It explains how go dep fundamentally works alongside the other tools.

If you have any skills or interest in this area, the dep team could use your help. Even just trying it out, running into trouble, and filing bugs would be helpful. Join #vendor on the Golang Slack.

Great initiative. If it goes well we hopefully will have an integrated dependency management solution with go command by next year this time.

The `dep` repository: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;dep" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;dep</a>

This podcast (iOS) is really worth listening. Straight from the horse&#x27;s mouth:<p>&quot;Dependency Management, Semver, and Community Consensus with Sam Boyer&quot; <a href="https:&#x2F;&#x2F;itunes.apple.com&#x2F;my&#x2F;podcast&#x2F;go-time&#x2F;id1120964487?mt=2&amp;i=1000382116565" rel="nofollow">https:&#x2F;&#x2F;itunes.apple.com&#x2F;my&#x2F;podcast&#x2F;go-time&#x2F;id1120964487?mt=...</a>

Started with dep recently on a real go project at work. It worked initially fine until I started adding dependencies and I had to hunt down the right commit hash by looking at the dependencies. I am probably going to stick with it and maybe contributing upstream as well.

Anyone know how dep&#x27;s approach differs from the two-step process in `gb`?<p>(gb vendor fetch github.com&#x2F;some&#x2F;pkg, gb build, git commit -am &quot;all of your vendor&#x27;d source&quot;)

Our team runs _the_ largest Go middleware. Checking in external dependencies into your repo scales - you don&#x27;t want 200+ users hitting Github every 10 minutes, when you can hit the local Git repo on a 10Gbps n&#x2F;w. Also, using GOPATH with a simple Makefile is pretty much all you need -- unless you don&#x27;t grok Makefiles. But whatever floats your boat and as usual the latest hotness sells.

I use gopkg.in. Personally I would like to see the community avoid adding more to the &#x27;go&#x27; tool. It is already doing too much. I think the solution provided by gopkg.in is better than other more conventional methods (e.g. npm or maven like). I love Go. But it is ironic that &#x27;go fmt&#x27; was designed in from the beginning. And now we are still dealing with semver and package dependencies. I went with gopkg.in because it made the dependencies a non issue from the tooling point of view. It is made possible by having &#x27;import&#x27; direct from the repositories, which archive different versions and tags. Perfect for something like gopkg.in. I am probably in the minority.