Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 octokit/go-sdk#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 tosrc
or something similar). Second, I was clinging to something that isn't that big of a deal: inside thepkg
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:
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.