The norm in Go is that project info lives, as much as possible, in the source files themselves--that includes dependencies, architecture-specific build tags, ca

The norm in Go is that project info lives, as much as possible, in the source files themselves--that includes dependencies, architecture-specific build tags, canonical import paths, etc. Also, as many steps as reasonably possible are accessible through the 'go' tool--testing, building, fmt, vet, get/install, etc.--even if the go tool has to invoke other programs on the local machine to do it (like how go get invokes git/hg, or go build can invoke a C compiler for cgo). This applies the "project info in the source" and "make stuff doable through the go tool" ideas to codegen. I don't think it's life-changing (I hope it's not too life-changing, i.e., that people don't go too crazy building hard-to-maintain Go-generating hacks) but it seems consistent.