How should I structure packages for a multiple-binary web application?

This is something we’ve been fighting and iterating on… Current layout on a reasonably sized project looks like this:

Godeps/
  ... lots of dependencies. This would probably be vendor/ if we started again today.
cmd/
  ... lots of binaries / main packages
etc/
  ... various example configs and stuff
gui/
  ... a web app that is compiled into one of the binaries
lib/
  ... our internal packages, some with subdirectories of their own.
  ... this was "internal" at some point, but since this is nowadays enforced and we
  ... actually have a few external uses, it became "lib"
script/
  ... various build supporting Go scripts
build.sh
build.go
README
AUTHORS
... etc standard toplevel stuff

There are a few more top level directories for stuff like graphics assets and so on as well, but not relevant to the Go side of things. So all the Go code lives under cmd/ and lib/, apart from build scripts.

This all builds with standard GOPATH (plus a prepend for Godeps), so internal packages are seen as github.com/organization/project/lib/thepackage.

I’ve been looking into gb as well, but I’m not entirely convinced yet.

2 Likes