[jff]

"go get" is kind of ok for trying out a new library quickly, but it's terrible for a real project.

Brad Fitzpatrick doesn't use it for Camlistore, instead he also does a Makefile-like system: https://github.com/bradfitz/camlistore

The sooner they deprecate the use of "go get", the better.

[iampims]

Brad is keeping a copy of all 3rd party libraries in https://github.com/bradfitz/camlistore/tree/master/third_par...

Is this the approach you recommend? I’ve never built a large go project, so I’m eager to learn what the best practices are.

[chimeracoder]

I would not use Camlistore as an example for typical Go best-practices. Aside from the fact that >30% of the project (by Github's estimation) is written in various other languages, the opening comment on the Makefile reads, "The rest of this Makefile is mostly historical and should hopefully disappear over time."

Also, GP is conflating the issues of (1) fetching dependencies, (2) building a project, (3) installing the project. Makefiles aren't inherently evidence against "go get"; there is no reason that "go get" couldn't call "make" instead of "go build" (which it does).

The main reason that (almost) no pure Go projects have Makefiles anymore[0] is because they're frankly not needed. The standard Go build tools[1] are more than sufficient.

Don't take my word for it, though. Hop on #go-nuts on freenode and ask the guys there (many of whom are core contributors) what they think of Makefiles. They'll tell you the same thing that they told me over a year ago when I tried to advocate the use of Makefiles in pure Go projects.

[0] For what it's worth, before Go 1.0 came out, projects had Makefiles. The fact that Makefiles were a part of the standard build process and later removed should be a hint as to what the idiomatic Go approach is considered to be.

[1] "go get" isn't exactly a build tool in this sense; it's a convenience wrapper for cloning using git/hg/etc., followed by "go build" and "go install"

[jff]

> Also, GP is conflating the issues of (1) fetching dependencies, (2) building a project, (3) installing the project. Makefiles aren't inherently evidence against "go get"; there is no reason that "go get" couldn't call "make" instead of "go build" (which it does).

Go get conflates those issues. It fetches dependencies, builds the project, and installs it.

You don't need Makefiles, you're right. You need a script that sets GOPATH and calls "go build".

The most important thing is to not depend on the whims of somebody else's repository. In the best case, they'll push an update and break your code for a while. In the worst case, they'll delete their repo; then you get to find your local copy, push it to github, and change all your source files to point to that.

Heaven help you if other people want to fork your project. Say I wrote "github.com/jff/bigproject", which depends on my package "github.com/jff/mypackage". Now, if Joe wants to fork the package and make a tweak, he also has to fork the main project and change all of its imports to point to github.com/joe/mypackage so he can compile and test it. Of course he can't very well push that, he'll have to revert the import changes again assuming I accept his pull request for mypackage. I've dealt with this in real practice when we had 3 people working on a project which imported 3 other packages. We were forever dealing with build failures and changed import paths and of course could hardly do a pull from one fork to another. It was hell.

Better to distribute the entire workspace, with src/ containing all the packages you need and nothing else.

[jff]

Yes, that's what I recommend. I don't recommend a Makefile for a pure Go project, you really just need a shell script that sets GOPATH and calls "go build". That's what we do and it works well.

[a-nom-a-ly]

> you really just need a shell script that sets GOPATH

No. :|