-
Notifications
You must be signed in to change notification settings - Fork 606
Add ability to override the source-package in mockgen #531
Comments
Hey @choo-stripe, I would like to have this issue sit a while for discussion from the community. I know there are other bazel users today and mockgen works for them from what I have heard. I assume this is because their build environment has Go in it. In general I don't think having Go in the environment is a bad thing. mockgen is meant to be a tool to generate mocks so you can write tests against. In order to run those test you will also need Go. |
Hi @codyoss, Thanks for the response! For context, the issue is not with the
|
Why can you not specify with GOPATH where your sources are? I feel like this could work? @linzhp I know you have talked about using bazel and mockgen in the past. Do you have thoughts here? |
@codyoss Thanks for tagging me. Yes! I have some thoughts.
I can give some context here. Before #420, mockgen used #420 removes the need for full I don't think this proposal can significantly improve the Bazel build performance over the combination of #420 and jmhodges/bazel_gomock#44. However, it would make mockgen more flexible, further breaking the tie to So I see this as a usability improvement, with the cost of supporting an extra flag in mockgen. |
To the point of
You can do this without writing a Bazel rule on your own. For example: load("@rules_proto//proto:defs.bzl", "proto_library")
load("@com_github_jmhodges_bazel_gomock//:gomock.bzl", "gomock")
load("@io_bazel_rules_go//proto:def.bzl", "go_proto_library")
load("@io_bazel_rules_go//go:def.bzl", "go_library")
proto_library(
name = "paxoshpb_proto",
srcs = ["paxosh.proto"],
visibility = ["//visibility:public"],
)
go_proto_library(
name = "paxoshpb_go_proto",
compilers = [
"@io_bazel_rules_go//proto:gogoslick_grpc",
],
importpath = "proto.example.com/paxosh",
proto = ":paxoshpb_proto",
visibility = ["//visibility:public"],
)
go_library(
name = "go_default_library",
embed = [":paxoshpb_go_proto"],
importpath = "proto.example.com/paxosh",
visibility = ["//visibility:public"],
)
gomock(
name = "mocks",
out = "mocks.go",
interfaces = [
"PaxosHClient",
"PaxosHServer",
],
library = ":go_default_library",
package = "paxosh",
)
go_library(
name = "go_mocks_library",
srcs = ["mocks.go"],
importpath = "mock.proto.example.com/paxosh",
visibility = ["//visibility:public"],
deps = [
":go_default_library",
"@com_github_golang_mock//gomock:go_default_library",
"@org_golang_google_grpc//:go_default_library",
],
) Note that the example use reflective mode of mockgen, because the generated source file in |
#547 should help with this issue. |
Requested feature A clear description of the desired feature and an example of
how it would be used.
There should be a way to specify the source-package such that mockgens requiring structs from the source file can succeed outside of a standard go environment.
For example, I should be able to pull a mockgen binary, and in a fresh docker container run:
Today, that'd fail.
Why the feature is needed A clear description of how this feature is not
served by existing functionality in gomock.
My end goal is to write a bazel rule that can mockgen for grpc clients. The great part about this is - as the proto schemas change, bazel will notice the dependency changed and re-run mockgen, ensuring the mock and source stay in-sync.
Currently
mockgen
uses standardgo
tooling to find the package of the source file submitted - go modules or poking around inGOPATH
. This makes it incompatible with build systems like bazel, which run their own go toolchain to compile go files. Bazel executes builds in isolated build environments, which don't necessarily have access to go modules or GOPATH.Now,
mockgen
is a tool. While it does go-like things i.e. codegen, the binary should be portable and able to execute outside of a go environment. The problem, obviously, is that mockgen can't really know the full package path for some arbitrary source file you give it, hence it relies on the go env.So! If only we could override the package where a source file comes from, it wouldn't require a full-blown go env setup (also the behaviour is a bit too magical right now), and we'd be able to portably call
mockgen -source=foo.go -source_package=my/foo
, such that the generated mock would properly import frommy/foo
.(Optional) Proposed solution A clear description of a proposed method for
adding this feature to gomock.
I wrote up a PR #529
The text was updated successfully, but these errors were encountered: