Comment by MetaCosm
12 years ago
What? It ONLY looks for localized copies.
When you have import "github.com/gorilla/mux"
it will look in
$GOROOT/src/pkg/github.com/gorilla/mux and $GOPATH/src/github.com/gorilla/mux
if it is missing, you can fulfill it with
go get github.com/gorilla/mux which will place it in the first place in $GOPATH
What are you talking about breaking with distributed teams? Since $GOPATH/src/github.com/gorilla/mux is in source control you NEED NOTHING and it will be a known working git clone.
EDIT: Additionally, it will never auto-update those dependencies (and break your build) unless you explicitly tell it to with "go get -u".
I know how it works :) I'm not new to Go.
BUT, what you are describing is exactly how the Haunt guys used Go and consequently the issues they have run into. Please re-read the update from Rick and read my comments again, you should then understand the issue and why changing the import path to a fork/clone/localized copy is beneficial (though not required).
I don't understand, so explain it to me like I am a child, I am certain I am missing something basic and the developers on the project aren't as dumb as it seems.
Seriously, it seems so goddamn basic. I am going to walk you through step by step how I would add an external library to my Go project.
#1. Switch to the go project directory #2. Fork for the new feature (adding_mux) #3. Run go get github.com/gorilla/mux #4. Add import "github.com/gorilla/mux" to my code, use mux for great goodness #5. Commit my code (this is commit of ./src which includes two things, the addition of the new github.com/gorilla/mux/* and my code using that new library) #6. Merge #7. Push
At this point, the commit that was just checked in doesn't need a change to its import path, will never break and will work as it was committed FOREVER. git clone FOO; go build BAR -- victory!
If at some point I want to update that library (new cool feature!)
#1. Switch to go project directory #2. Fork for updating library (update_mux) #3. Run go get -u github.com/gorilla/mux #4. Write code using new awesome features #5. Commit my code (again, "my code" in this case is both the update to the mux library, and my new usage of it, again committed together for great goodness!) #6. Merge #7. Push!
I feel like one of us is bat shit insane, and at this point, I am just hoping it isn't me.
EDIT: Another cool side effect of this is you end up with localized hermetic copies of your code with references for posterity to where you got it, bonus points!
EDIT 2: For reference, there are various forks of the source he "released" (abandoned? Sold for 28k? whatever) ... I think you can start looking at the github network from here: https://github.com/runningwild/haunts
So the key part of the update I was referring to was the following:
In short, original developer has the clone of the OpenGL library in their 'src' directory. While working on Haunts his making changes to it and not pulling updates from upstream. All is well, things will always build on his machine because as you say, it won't update unless he does 'go get -u'.
Fast forward to when the community takes over, they clone the Haunts project and attempt to build it. Now they are using the HEAD of the 'github.com/go-gl/opengl/gl' repository, 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 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.
1 reply →