I had issues on how to separate dependencies in totally different projects using GoLang. i.e. If I update one global(user-local) dependency in a GoLang project - how do I ensure that the other projects won’t break and won’t require any change when a dependency is updated.

For example, I might have projects like this:

/client1/proj1/goapp/...

/client2/proj2/goapp/...

I surely do not want proj1 and proj2 dependencies to be the same. And as seen in the path structure, goapp is a part of a larger project

How do i fix this?

A way to do so is to set different GOPATH for different projects.

But GOPATH can be a list of multiple paths - we want to make sure that we use project paths only. The dependency installation with go get installs in the global(user-local) paths by default. This default behavior can lead to undesired outcomes.

Why not just use vendor directory instead?

The vendor directory dictates that the code is placed under $GOPATH/src

If you are okay with adding new project directories to global GOPATH and comfortable with the directory structure it dictates - you could fetch a specific revision of a dependency with govendor and not use the boilerplate below

See this:

OR

And when you do go get ..., it pollutes(read:forces) into the src directory. Probably, it make sense for Google (a large org with many devs on similar projects). I don’t want that inflexibility.

A possible solution

The boilerplate code in this repository avoids the default behavior with a few scripts:

GoLang-Project-Structure

Can we still use vendoring solutions like govendor?

I believe yes! Just use govendor fetch ... instead of go get ... in the installdeps. It will work because the GOPATH is already set to the project directory (I haven’t tested this part)

I like govendor. But considering the state of dependency management in Go, I prefer to merge all the dependencies right into my repository (except for this demo). I hope I can stop doing that sooner.

If you do not want to merge fetched repositories, use govendor or something similar. And add dependencies to your .gitignore.

Should you use this setup always?

It could be a pain to setup a repository this way when you are writing throwaway code. This setup will help when a project grows.