People may just not want to have their source code into a special hierarchy where their own source code is mangled with the source code of the dependencies.
I also use a Makefile to setup an ad hoc GOPATH to workaround this.
Me too. I work under the assumption that a packager can just grab the tarball of the latest stable tag from the repo's releases page on Github, unpack it somewhere and `make && make install`. I converged upon the same approach of setting up an ad-hoc gopath.
I'm not a big fan of the make && make install route.
I'm not thrilled about the GOPATH either. Not least because there is no really clean solution for actively developing code inside the GOPATH and working with GitHub.
Also, I would have liked dependencies to be automatically downloaded and installed in a local cache rather than me having to crap it into the GOPATH by manually issuing a "go get". I had hoped we were done with that.
But I can live with it because it requires no explanation to new developers on a project.
Using some hack to "solve" problems means forcing developers to learn even more stuff before getting started on projects. And one might say "but it is only one small thing", but that has sort of been the mantra in the Java world. And it isn't so small when you spend 2 weeks learning Java and 5 years learning about the little small things that have been put in any non-trivial project.
> But I can live with it because it requires no explanation to new developers on a project.
Even if it does, I'm a big fan of still mentioning it in the README. For my Go projects, it's usually just one sentence: "This project is go-gettable, or you can make && make check && make install". Avoids a lot of useless confusion.
Actually, I'm starting to think that the solution is to have per project GOPATH instead and build switching into the shell or the editor. Because messing with Makefiles is just about the last thing I'd like to do (it never stops there. it always escalates)
I also use a Makefile to setup an ad hoc GOPATH to workaround this.