Ever since Go caught significant attention outside of , dependency management has been a hot topic. Google Initially, there was no dependency beyond , which loads source files off to your system-wide . With internal dependencies, this often works since everyone is expected to use the latest version. However, for teams with 3rd-party dependencies, this was unacceptable due to mismatches, conflicts, breaking changes, and more so a number of approaches emerged, e.g. management go get origin/master [$GOPATH](https://github.com/golang/go/wiki/GOPATH) ad hoc committing a project-specific $GOPATH git ( ) submodules and variations tools that automated switching between project-specific like and $GOPATH [gvm](https://github.com/moovweb/gvm) [gb](https://github.com/constabulary/gb) Eventually, folks realized we needed something better… something that was consistent and actually kept track of actual versions (commit SHAs, tags) that code committed was on… something that was simple. To “solve” this need, the most popular solution — — rose to popularity. Godep allowed you to “easily” [godep](https://github.com/tools/godep) pin dependencies in your to a project $GOPATH copy dependencies from a project to your $GOPATH browse what dependencies are pinned via Godeps.json Though Godep was an immense improvement over existing methods, it certainly didn’t solve everything. It had a number of problems. For one, Godep had a number of bugs, quirks, and inconsistencies that frustrated its users. Many people believe this killed the project. . I disagree Most of these “quirks” were because Godep still revolved around . To update a project’s dependency, you’d have to update it in your via , and then, copy it from your to your project’s via . Since most developers work out of , this was annoying when you were modifying a dependency in . Additionally, since most developers have a single , updating dependencies of multiple projects using different versions of dependencies concurrently was overwhelming. $GOPATH $GOPATH go get -u github.com/some/dep $GOPATH Godeps/ godep save github.com/some/dep $GOPATH $GOPATH $GOPATH By Go 1.5 (mid-2015), there were a number of different practices but no standards. So the Go team realized it was time to step in by drafting the “ ”. With the experiment enabled, Go’s preferred the folder to . In Go 1.6, the vendor experiment was enabled by default. Immediately, numerous tools blew up, e.g. vendor experiment import vendor $GOPATH/src , an opinionated, heavy, and “modern” package management system… very similar to ruby’s gems glide , a happy in-between… my personal favorite, though it has arguably strange naming/syntax conventions govendor , a simple vendoring tool… the godep of vendor gvt … and , many many more Not to undermine what it takes to integrate something like this into the core toolchain, but beyond the 4-page proposal and hype, “vendor” didn’t introduce much that wasn’t already around. already did everything it proposed and more. godep build Note that when “go get” fetches a new dependency it never places it in the vendor directory. In general, moving code into or out of the vendor directory is the job of vendoring tools, not the go command. — From Go 1.5 Vendor Experiment proposal In fact, vendor didn’t even come with a tool to manage the dependencies or get them in in the first place. However, what it did was provide the community with a standard of how and where dependencies be managed. And, apparently, that’s often enough to get the ball rolling in a software community. vendor/ should Vendoring in Go is . Fortunately, the Go team is working on a new tool — — that should improve things significantly. So far, all the problems I’ve had with Go dependencies are solved in their and documents. Of course, there’s no guarantee that these features will be solved in the initial release, but it’s great to know that the team recognizes and is interested in solving them. From supporting forks to transitive dependencies to multiple versions of the same dependency to supporting private proxies, I’m really excited for . still very broken [dep](https://github.com/golang/dep) features user stories dep Go is for simplicity. Simplicity is for productivity. Not having to fight dependencies will be a huge plus! 🎉 is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
