Hard to provider rules_go examples / tests

[mattmoor]

Challenge

I provide Bazel rules. I want to add Go examples / tests. I do NOT want to require all users of my rules to import rules_go.

Today to use rules_go, three main elements are required.

1. Import rules_go in WORKSPACE
2. go_prefix in /BUILD.
3. go_binary in .../BUILD.

It is this second requirement that is problematic because it is on the BUILD path that Bazel loads for every .bzl file in the repo.

Strawman

I think the simplest solution would be to enable folks in my situation to override the baked-in //:prefix target, so that we can move it into .../BUILD and enable rule consumers to dodge the rules_go requirement.

[ianthehat]

go_prefix is problematic for a couple of reasons, and we would like to get rid of it rather than fix it.
go_library was modified to support importpath a while ago. If that parameter is set, the _go_prefix is ignored, but unfortunately still has to be present.
The current plan is to change gazelle to always write out the importpath for all rules, remove the _go_prefix attribute and then finally deprecate and remove the go_prefix rule.
Would that meet your requirements?

[mattmoor]

Even better, is there an issue I can follow, which once done will enable me to write things in a way that meets my needs?

[jayconrod]

I think we've mentioned deprecating go_prefix in passing in a few places, but we didn't have an issue for it. I've created #721 to actually track this.

I'd like to understand your problem a little better though. Are you providing macros that instantiate Go rules in users' repositories? If so, I see how it can be annoying to require users to define their own go_prefix when it's apparently not needed.

Even if go_prefix is not required, your users will still need to include @io_bazel_rules_go as a dependency in their WORKSPACE file. WORKSPACE is a flat list of all dependencies, including transitives. You can hide this by declaring dependencies in a macro that you provide.

[mattmoor]

Are you providing macros that instantiate Go rules in users' repositories?

In some cases yes, in others no. In the cases where I am, it is absolutely my expectation that folks would include the Go rules prior to mine.

I'm happy to GVC, it might be easier to explain? My username is my GitHub handle @google.com