← Back to context

Comment by MetaCosm

12 years ago

No need to fork, it puts a copy of those libraries under ./src, so you always have a sealed (hermetic) referentially complete copy.

You don't bet your production software on things randomly downloaded from the internet at compile time. This is why go never auto-updates when you do "go get", you have to explicitly use "go get -u".

Always localize what you depend on, you never know when a github repo could be pulled, go offline, be renamed, a lawsuit could break out making the library vanish. There are TONS of reasons you should ALWAYS localize your dependencies for building software.

EDIT: This has the amazingly cool side-effect of meaning even on complex projects, you can just do a git clone and then go build FOO and it just works, no nonsense, no fuss, and it is EXACTLY in the state it was when it was checked in -- no surprises.

> No need to fork, it puts a copy of those libraries under ./src, so you always have a sealed (hermetic) referentially complete copy.

While that is true, it doesn't solve the problem with distributed teams. The library path MUST be pointing to a 'localized' repository to solve the problem the Haunt guys are having.

  • 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).

      3 replies →