Go rules: Support specifying custom package name

[ivucica]

Issue

Go rules currently assume that the Go package name matches the directory path (Bazel package name) from workspace root onwards, plus the build rule name. This is not always true, especially if, for technical reasons, a single BUILD file describes a tree of Go sources.

Proposed fix

Users should be able to specify a custom Git package name in at least the go_library() build rule.

I believe that the main change would be to allow overriding the source_import variable referenced in line 164 of //tools/build_rules/go:def.bzl.

Background

I have a small project where a bunch of external Go dependencies are stored as Git submodules in folder vendor. This lets me build the project trivially with the go tool while specifying the exact Git commit I want to use for my build. I do not want to check in full copies of the projects I depend on, to avoid bloating the main repository's size, and to be able to version dependencies separately.

Using slightly modified Go rules from Kythe, I've created //vendor/BUILD which lists various Go packages and their dependencies. ¹ Build targets were named approx. //vendor:github.com_someaccount_someproject (i.e. replacing slashes with underscores in target names) because target names, as far as I know, cannot contain slashes in them.

Because the dependencies are stored as submodules, I cannot add BUILD files. I've been thinking about using external repositories to drop in a BUILD file, but sometimes a single Git repository contains multiple packages. As far as I know, I can only drop in one BUILD file, so the project-specific root BUILD file would still have to describe the subpackages. Therefore, I would replace the problem of having labels such as //vendor:github.com_someaccount_project_subproject with having labels such as //vendor/github.com/someaccount:project_subproject, which would generate the broken go package name of github.com/someaccount/project_subproject.

Feel free to reach out to me over IM if clarification of the described scenario would be useful. The described small personal project is not currently published.

Footnotes

1. This has worked fine, but my modifications are somewhat brittle if I want to split up the BUILD file to at least "one per non-submodule directory" (i.e. out of //vendor/BUILD and into //vendor/github.com/someaccount/BUILD). I would also strongly prefer using the upstream rules. ↩

[damienmg]

Note that we are always happy to accept contribution :)

[damienmg]

This was transferred to bazelbuild/rules_go#16