Deprecate and remove go_prefix

[jayconrod]

go_prefix is used to translate Bazel labels (for example, //foo/bar:go_default_library) to Go import paths (example.com/repo/foo/bar) and vice versa. There are a number of problems with go_prefix, and we'd like to stop using it and eventually stop supporting it.

• Go rules implicitly depend on //:go_prefix. This means there must be a go_prefix defined in the repository root package, even if there are no other Go rules in that package.
• This does not work well for Go subtrees that are part of larger repositories. The actual import path of libraries within the repository may not correspond to <go_prefix>/<subtree>/<library>.
• This does not work for vendoring. We have special cases for vendoring in several places.
• It's confusing and unexpected that go_prefix is required for go_binary. For binary-only repositories, it shouldn't be required at all.

We would like to move away from using go_prefix. go_library already has an importpath attribute, which allows the import path to be set explicitly. This is currently optional, but it may be required in the future.

We will deprecate go_prefix slowly in several steps to avoid breaking people.

• Gazelle will add importpath attributes to new and existing go_library rules. These import paths will match the import paths that already would be computed, based on the current go_prefix and the relative path within the repository.
• go_prefix will no longer be mandatory for go_library rules that specify importpath. We should be able to accomplish this with computed dependencies.
• Gazelle will no longer generate go_prefix rules. When Gazelle is run with the "fix" command, it will remove existing go_prefix rules.
• At some point in the distant future, we may remove go_prefix altogether (this might not actually happen, but it's the plan of record).

[nictuku]

Not sure if it's related, but do we need importpath on go_binary and go_image? One currently has to set either //:go_prefix or importpath when calling that rule. As a user new to open-source Bazel, this seems confusing.

Does this Issue about go_prefix also imply that the importpath requirement will also eventually be removed? That would be nice.

[jayconrod]

At the moment, importpath is needed for go_binary if //:go_prefix does not exist. I can't comment on go_image.

Internally, a go_binary rule describes a package that needs to be compiled, just like go_library. The importpath determines the filename for this package. The difference is that go_binary gets linked and doesn't get imported by other rules, so the filename doesn't matter much for compilation.

The one place it is used publicly is the experimental go_path rule, which pulls all the sources for a set of rules into a GOPATH-like directory tree. go_path uses importpath to determine where to put sources in that tree. There are some experimental rules based on go_path, like go_vet. It's likely that we'll need to run any tool that requires a GOPATH on top of something like this, so the importpath attribute will continue to be important.

[mattmoor]

go_image is a pass-through to go_binary (at the version the user imports) so it's requirements shouldn't be any different.

[nictuku]

If go_prefix is going away, all go_binary will have importpath and that's confusing for a Go binary. IIRC, internally at Google, importpath was not required for go_binary.

Can we use a convention for the path of go_binary that can stand-in when importpath isn't set?

[ianthehat]

gazelle writes the importpath into the rule for you, so it will always be set anyway.
We are trying to make sure that heuristics and conventions live in gazelle, not the rules.
The idea is that the build files tell you everything you need to know, rather than making you guess what will happen, and that a little verbosity is fine so long as you don't have to update it by hand.

[jayconrod]

Closing old issues.

go_prefix is gone. go_binary does not require importpath, but go_library does.