I've been thinking about this a lot. There's no question I've been one of the more staunch defenders of the pkg directory; I like the cleanliness of a root directory with the source code tucked into a neatly identifiable folder.
However, there's also no question I've been outvoted on this front, and as I work through what nice client abstractions might look like in https://github.com/octokit/go-sdk/pull/52, I'm debating going the other way. First, there's the repetition in any top-level Go file: package pkg, which is ugly (though it could be remedied by switching to src or something similar). Second, I was clinging to something that isn't that big of a deal: inside the pkg directory of go-sdk on the rate-limiting branch, there's only four other directories, which even if expanded wouldn't be the end of the world.
Also, I've read our esteemed GitHub colleague Dave Cheney's post here, which mentions:
Possibly because of the early use of a pkg/ directory to hold package—and the corresponding cmd/ directory to hold commands (package main) this practice of putting your packages in an empty pkg/ directory has spread to other Go projects. This practice was never a recommendation, just a result of the original Makefile based build system.
In September 2014, the stdlib moved away from storing package code in an otherwise empty pkg/ directory, and you should follow their lead. Other than a superficial symetary [sic] with cmd/ putting packages in a pkg/ directory is needless boilerplate and distracts from the potentially more useful internal/ directory.
One thing that does concern me a bit is that removing the pkg directory would mean any code currently in Go files immediately belonging to that folder would have to find a different directory in order to continue to be exported. This could lead to repetition or potentially poor naming elsewhere as package names are forced.
I've been thinking about this a lot. There's no question I've been one of the more staunch defenders of the
pkgdirectory; I like the cleanliness of a root directory with the source code tucked into a neatly identifiable folder.However, there's also no question I've been outvoted on this front, and as I work through what nice client abstractions might look like in https://github.com/octokit/go-sdk/pull/52, I'm debating going the other way. First, there's the repetition in any top-level Go file:
package pkg, which is ugly (though it could be remedied by switching tosrcor something similar). Second, I was clinging to something that isn't that big of a deal: inside thepkgdirectory of go-sdk on the rate-limiting branch, there's only four other directories, which even if expanded wouldn't be the end of the world.Also, I've read our esteemed GitHub colleague Dave Cheney's post here, which mentions:
One thing that does concern me a bit is that removing the
pkgdirectory would mean any code currently in Go files immediately belonging to that folder would have to find a different directory in order to continue to be exported. This could lead to repetition or potentially poor naming elsewhere as package names are forced.