That wasn't a binary distribution problem or anything like one, was it? That was as I remember it a development team that simply hadn't created a known-good repository of their third-party dependencies. While I grant you that's a common pitfall in the rubygem era, it's hard to feel much sympathy as someone who came up building commercial C code, where not having a one-command third-party build-world system was a cardinal sin.
Create a known-good repository of third-party dependencies is so easy in Go. Change the $GOPATH, `go get` all the dependencies and add that folder to version control.
I think I agree. Also, for all the complaints about "magic" in Rails, there's nothing more magical in both Rubyland and Pythonistan than package management, and the explicitness of Golang's "package" system is a welcome contrast.
> there's nothing more magical in both Rubyland and Pythonistan than package management,
Could you expand on this a bit? I'm interested in your opinions, as it's hard to see from the inside. In Ruby, it's just things modifying the $LOAD_PATH, which should be basically the same as changing your $GOPATH, no?
I don't know much / anything about ruby package management, but if it's commonplace for ruby packages to change the LOAD_PATH (which I guess is similar to PYTHON_PATH / sys.path in python ?), that is really quite magical (by which I mean, causes unexpected behavior).
What conroy is talking about is creating a static set of dependencies that you check into your own source control, because go doesn't let you specify e.g. github commit hashes to "pin" a package dependency to a certain revision.
So a workaround for that is to (as a one-off) change your GOPATH ($GOPATH/src and $GOPATH/bin is where the standard "go get" / "go install" etc put things) to something temporary, "go get" your dependences (which will fetch them from github or wherever at the HEAD revision). Now run your test suite to make sure everything passes. If it does, great, take the current $GOPATH/src and check the contents of that into your own revision control. Et voila, ghetto-"pin"ning.
The packages themselves don't change the LOAD_PATH. rubygems/bundler do. Both explicitly add the paths given in the gemspec (lib/ by default). I wouldn't call that "magical".
