Glide[1] is a tool like Composer but for Go and it uses the vendor/ directory. It's designed to complement the go commands.
disclosure: I'm one of the glide devs
Glide[1] is a tool like Composer but for Go and it uses the vendor/ directory. It's designed to complement the go commands.
disclosure: I'm one of the glide devs
That's why I include the statement that Go vendoring is useful "(at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)"
Now that I've looked into glide a little more I'm curious: since the main benefit is the ability to use semantic versioning to manage your dependencies, why do you use a glide.lock file instead of making the "glide" command a simplified way to update/maintain vendor submodule references with semantic versioning? Then users wouldn't need the glide tool, only developers, and users could just use standard go tools.
- The Go community supports Git, Svn, Bzr, and Hg. We keep that up. According to the Eclipse community survey, 2014 was the year Git usage passed Svn usage. Svn usage is still quite high. - A lot of developers struggle with and even have strong negative opinions of submodules. So much so that we now have subtrees. I've find a lot of developers would prefer not to use them. - The way Glide works is in line with the package managers from the other major/popular languages. This way it's familiar to many people coming to Go by solving the same problem in the same way they're already used to.
Also, there's some good discussion of other approaches to dependency management on the go forum: https://forum.golangbridge.org/t/the-best-dependency-manager...