-
-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gazelle adds dependancy on @com_github_golang_protobuf//ptypes/descriptor:go_default_library, which doesn't exist. #940
Comments
I'm having the same issue. I'm attempting to build a protobuf which requires My
The protobuf file is at Here is
When I execute
I attempted to add a
I spent much of yesterday fighting |
The proto rules are not really documented because they are not stable yet, although at this point the main rule is probably stable unless a huge missing feature turns up but the toolchains are definately not. |
That's strange, then, as |
* When resolving proto_library dependencies, a vendor/ prefix will no longer be added in any case. These rules can't build because the protoc import paths are not modified (and can't be right now). * go_proto_library dependencies for Well Known Types will be resolved to something in //vendor/github.com/golang/protobuf. This will change in the future when we have better support for alternative proto toolchains. * There is now a special case for google/protobuf/descriptor.proto. Fixes bazel-contrib#888 Related bazel-contrib#940
@tomwilkie #945 will address this, but not for gogoprotobuf (yet); it adds a special case for descriptor.proto to resolve to github.com/golang/protobuf. #944 is a proposal to turn WKT targets into implicit dependencies in How are you using gogoprotobuf otherwise? Are you defining another toolchain? @bluedragonx You can make rules you don't want Gazelle to update with |
@ianthehat did the implementation for weaveworks/cortex in cortexproject/cortex/pull/564. He does define another toolchain. AFAICT he got it all working, I was trying to get a new protobuffer branch on weaveworks-experiments/loki building with it too, when I hit most of them problems. I can prepare a PR with the reproduction if that would help, but it will take me a while to clean it all up. |
Ah, I forgot about that implementation. As a workaround until #944 is fixed, you should be able to generate/update rules with Gazelle, then use |
Neat, will give that a go. I'm not blocked right now (on this at least). Currently battling with vendoring the k8s client... |
Thanks @jayconrod. I'll give #945 a shot. |
* When resolving proto_library dependencies, a vendor/ prefix will no longer be added in any case. These rules can't build because the protoc import paths are not modified (and can't be right now). * go_proto_library dependencies for Well Known Types will be resolved to something in //vendor/github.com/golang/protobuf. This will change in the future when we have better support for alternative proto toolchains. * There is now a special case for google/protobuf/descriptor.proto. Fixes #888 Related #940
This is working for me now. Thanks for the help! |
And in #1170 we now fully support gogo from rules_go directly. |
This comes from trying to vendor github.com/gogo/protobuf.
The text was updated successfully, but these errors were encountered: