Support the root of code built with rules_go starting under a subdirectory.

[ains]

Our repository structure means that all of the code built with rules_go does not start at the root of our Bazel workspace, but in a subdirectory.

This means that a package with importpath "improbable.io/server/foo" would live under the workspace at directory "go/improbable.io/server/foo".

So that we don't have to rewrite all of our importpaths we have a patch which adds an option called prefix_root which specifies the directory at which the go portion of a workspace will begin. improbable-io@512545a

#458 does support this, and is more general, but would require us to specify the import_path in every one of our build targets which seems slightly more complex than a simple directory offset.

Opening this ticket to discuss and see if there are any strong preferences for either approach

[ianthehat]

I looked very hard at what you did before writing #458, and decided there was no good way to generalise it. The limitation of only one root per repository is too limiting, and any attempt to allow multiple roots ends up with adding an extra attribute to every go library anyway, but in ways that make it harder to understand than a simple import path. The clearest I could manage is to make the go prefix attribute of a go library not hidden, so it can be set, and then you can tell each library where it's root prefix is, and then work out the relative path from the prefix location to the library, but it's not pretty.

The advantages of #458 are that it also enables layouts where the package import path is not even slightly related to the file layout, and also allows multiple versions of the same package to exist in the same build (if you build two binaries that need different versions of the same common library for instance, that will work find with this system).
For all the libraries I have seen in golang/x for instance they set the canonical import path in the go files, if gazelle used this information to populate the import_path line on the go_library, then there would be no extra work to maintain these, and it makes the go_prefix system irrelevant. It also means you could drop any package anywhere you like in your repository, and move it if you want to later, and it will just work.

[ianthehat]

i'm going to close this on the assumption that the importpath declaration allows the desired pattern, and that the plans in #721 to kill go_prefix and improve gazelle to always generate the importpath declaration are an acceptable plan of action.
Please either re-open or comment on #721 if you don't agree, thanks!