travis jeffery
Most people who would bother with the matter at all would admit that the layout of Go projects is in a bad way. To pkg, or not to pkg, that is the question. To put your project’s libraries under a directory named pkg, or not?
The pkg convention started when, prior to Go 1, the Go team put the stdlib in $GOROOT/src/pkg. Later they deleted the pkg directory and moved the stdlib to $GOROOT/src. (Brad Fitzpatrick talked about the history on Twitter.) By that time, projects like Kubernetes, Docker, Etcd had adopted pkg in their own projects.
Go doesn’t have an official project layout so the choices popular projects make are as close as the community gets to having a standard. These projects are often the first projects that Go programmers learn from. A GitHub repo called golang-standards/project-layout with 11K stars recommends pkg. Most of the most popular Go projects use pkg. New Go programmers ask why I don’t use pkg. I don’t see pkg going away unless the Go team publishes a doc that recommends not to.
You use internal directories to make packages private. If you put a package inside an internal directory, then other packages can’t import it unless they share a common ancestor. Internal packages enable you to export code for reuse in your project while reducing your public API. Russ Cox, in his proposal for internal packages, used the standard library as an example of where you want them. In the standard library, you:
