access to the genfiles of a target?

153 views
Skip to first unread message

je...@somethingsimilar.com

unread,
Apr 16, 2017, 6:26:53 PM4/16/17
to bazel-discuss
I'm stuck trying to get a mockgen[1] target to work on a go_proto_library target. mockgen expects either a) a working GOPATH (which rules_go currently doesn't provide to it) or b) a file path to the specific code file that holds the interface you want to create a fake for.

I've had success before where I was in the same package and new which files to inspect in the mockgen target, but I can't seem to easily get to the genfiles of another distant, generated target without resorting to assuming things about the filepaths bazel uses.

I'm not sure how to do this programmatically inside of bazel. Is there a way to get to the genfiles a target creates from another target?

[1] https://github.com/golang/mock

Brian Silverman

unread,
Apr 17, 2017, 2:03:51 AM4/17/17
to je...@somethingsimilar.com, bazel-discuss
I'm not familiar with the Go rules, but the way to get access to that information is via the transitive info providers of the rule. I often find the easiest way to work with unknown/underdocumented rules is to just print what's there and see if anything looks like what you want. `print('%s' % dir(ctx.attr.attr_name))` where attr_name is deps or srcs or whatever you called the attribute where the label of the go_proto_library rules are will get you names of all the providers, and then you can drill down from there. Once you find a File which is what you're looking for, path is the way to get a path to it. Digging around with paths manually is a recipe for making non-hermetic rules which don't rebuild properly, so avoid that.

Another way to figure out how to work with the Go rules is to look at their implementation see what they provide. As mentioned in the documentation, whatever the rule implementation function returns is (basically) what you can access, so look at what's there.


--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/531572c7-b500-4242-9297-d899f31d941a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jeff Hodges

unread,
Apr 17, 2017, 3:16:28 AM4/17/17
to Brian Silverman, bazel-discuss
Thanks!

I dug in a little bit more into the rules_go code and the genfiles stuff was all in a private target type (_go_proto_library_gen) depended on by the public one (go_proto_library). Unfortunately, the simple fix I thought I could once I had the generated file (using a small patch to rules_go to expose the private target type) didn't work out. It didn't work out because mockgen has a tricky bug that was closed as a WONTFIX in favor of pushing people to using the GOPATH dependent version. 

I left a comment on a relevant ticket in rules_go (and in mockgen) but I'm officially back to stuck. It seems any time you generate mocks from outside of the package, the types used in the interfaces won't get re-written from `Dog` to `originalpkg.Dog`. https://github.com/bazelbuild/rules_go/issues/71#issuecomment-294380698

I'm not sure how folks are doing Go mocks where they don't control the source code. Would love to hear from some folks using bazel/blaze with Go on how they are doing this.

On Sun, Apr 16, 2017 at 11:03 PM Brian Silverman <bsilve...@gmail.com> wrote:
I'm not familiar with the Go rules, but the way to get access to that information is via the transitive info providers of the rule. I often find the easiest way to work with unknown/underdocumented rules is to just print what's there and see if anything looks like what you want. `print('%s' % dir(ctx.attr.attr_name))` where attr_name is deps or srcs or whatever you called the attribute where the label of the go_proto_library rules are will get you names of all the providers, and then you can drill down from there. Once you find a File which is what you're looking for, path is the way to get a path to it. Digging around with paths manually is a recipe for making non-hermetic rules which don't rebuild properly, so avoid that.

Another way to figure out how to work with the Go rules is to look at their implementation see what they provide. As mentioned in the documentation, whatever the rule implementation function returns is (basically) what you can access, so look at what's there.

On Sun, Apr 16, 2017 at 3:26 PM, jeff via bazel-discuss <bazel-...@googlegroups.com> wrote:
I'm stuck trying to get a mockgen[1] target to work on a go_proto_library target. mockgen expects either a) a working GOPATH (which rules_go currently doesn't provide to it) or b) a file path to the specific code file that holds the interface you want to create a fake for.

I've had success before where I was in the same package and new which files to inspect in the mockgen target, but I can't seem to easily get to the genfiles of another distant, generated target without resorting to assuming things about the filepaths bazel uses.

I'm not sure how to do this programmatically inside of bazel. Is there a way to get to the genfiles a target creates from another target?

[1] https://github.com/golang/mock

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages