-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
deps: move from github.com/golang/protobuf to google.golang.org/protobuf/proto #7059
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #7059 +/- ##
==========================================
- Coverage 82.47% 81.19% -1.28%
==========================================
Files 305 345 +40
Lines 31383 33925 +2542
==========================================
+ Hits 25884 27547 +1663
- Misses 4442 5205 +763
- Partials 1057 1173 +116
|
This seems reasonable. But I think it's also possible, if you want, to create a proto file and import it instead of doing it dynamically like the test currently does.
I'm not sure. Can you do |
For now, I found a simpler solution that does pretty much the same as before: func init() {
// Ad-hoc registering the proto type here to facilitate Unmarshal of OtherSecurityValue.
m := (*OtherSecurityValue)(nil)
s := "grpc.credentials.OtherChannelzSecurityValue"
mt := protoimpl.X.LegacyMessageTypeOf(m, protoreflect.FullName(s))
if err := protoregistry.GlobalTypes.RegisterMessage(mt); err != nil {
panic(err)
}
} We are still using legacy way of registering messages but not the deprecated dependency. The main problem I have with having a proto file or registering a descriptor is that it is not linked to
Doing: err := proto.UnmarshalText(want[i], w)
if err != nil {
t.Fatal(err)
}
_, err = prototext.Marshal(w)
if err != nil {
t.Fatal(err)
} there are not errors returned... |
We wouldn't expect errors. I was curious what the output would look like as that should really be something that would be accepted by |
The issue seems to be coming from the function called |
I believe we could also remove this line in vet.sh: # - Ensure all ptypes proto packages are renamed when importing.
not git grep "\(import \|^\s*\)\"github.com/golang/protobuf/ptypes/" -- "*.go" Other than that, if there is no way to remove the dependency in |
Good find! Thanks for the fix.
I'm fine with that, but if we do that we should replace it with something that looks for |
channelz/service/service_test.go
Outdated
"google.golang.org/protobuf/protoadapt" | ||
"google.golang.org/protobuf/reflect/protoreflect" | ||
"google.golang.org/protobuf/reflect/protoregistry" | ||
"google.golang.org/protobuf/runtime/protoimpl" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WARNING: This package should only ever be imported by generated messages. The compatibility agreement covers nothing except for functionality needed to keep existing generated messages operational. Breakages that occur due to unauthorized usages of this package are not the author's responsibility.
I'd rather not use this package if it's at all possible to avoid it, unless you are extremely sure backward compatibility will be guaranteed for all our uses of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I agree that using protoimpl is half a solution. I'm figuring out how to imrpove this.
@dfawley I found other references to github.com/golang/protobuf and I changed the vet.sh. Could you check? The GetSocket test seems to fail and not consistently (flaky). Not sure why yet. editIt seems to be the order into which the value is encoded in
And the values in |
@dfawley It was because protobuf does not ensure encoding order of fields. Going with a generated proto message is easier. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me. Just one change to request. Thanks!
channelz/service/service_test.proto
Outdated
|
||
package grpc.credentials; | ||
|
||
option go_package = "google.golang.org/grpc/channelz/service"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this go into service_test
? If not, please put it in a subdirectory so it doesn't get pulled into the production build. (Even if it is eventually pruned out (?), it still feels wrong.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's why I wanted to keep it as a descriptor in the test file at first... I think I will move the info back into the test file like it was and create the ProtoReflect function on OtherChannelzSecurityValue
.
@@ -287,5 +287,5 @@ type ChannelzSecurityValue interface { | |||
type OtherChannelzSecurityValue struct { | |||
ChannelzSecurityValue | |||
Name string | |||
Value protoadapt.MessageV1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be a breaking change. It is probably fine since it's experimental, and it's unlikely anyone is using it....so I think I'm OK with it. Just wanted to call it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks @Clement-Jean for making huge strides in fixing #5316.
gRPConf 2024 Registration is now open! Please find more details at grpc.io. Hope to see you there.
@dfawley @arvindbr8 this is the next step after #6919 since #6969 is closed.
I'm still unsure about the remaining deprecated dependency in channelz/service/service_test.go. First, this line:
it seems to be possible to use
protoregistry.GlobalTypes.RegisterMessage
instead ofproto.RegisterType
. I just don't know how yet.Second, it seems that
proto.UnmarshalText(want[i], w)
andprototext.Unmarshall(string(want[i]), w)
are not doing the same thing. The first one accepts '\x00' in the string and the second does not. Any idea why?RELEASE NOTES: none