opengl

call it forking, I call it localizing), they would have had the EXACT same version as him and they would not have had to fulfill that dependency on their own. Also, the same import path would continue to work off this local checked in version. > By forking, or maintaining your own copy of library, you get a level of isolation from the upstream developers. I thought that maintaining your own local copy of libraries under /src was the norm for go developers, as the value of hermetic checkouts goes hand in hand with some other Go'isms like static built binaries.

ry, as specified by the imports path and they find that it no longer compiles. This is where the problem exists. The simplest way around this problem is to simply fork the OpenGL Go library (like they have), and reference the fork in the import path. That way no matter what happens in the upstream repository, the Haunts project will continue to compile. The original developer could of then just pushed the changes he was making in his local 'src' directory back to the fork and everything would be fine. When they are ready to take updates from upstream, they simply update their fork and then 'go get -u' on all developer machines. By forking, or maintaining your own copy of library, you get a level of isolation from the upstream developers. What you are saying is 100% correct, the Go tools automatically give you this when running 'go get', it clones the library into your 'src' directory. What I am saying is that when working in a team/community environment, you need an additional level of isolation (the fork), so that the entire team can be using the exact same version of the library. > I feel like one of us is bat shit insane, and at this point, I am just hoping it isn't me. I don't think (hope) either of us are, just not thinking on the same track :) I hope what I've written is clear enough that you can see what I was saying.