-
Notifications
You must be signed in to change notification settings - Fork 4.5k
move from github.com/golang/protobuf to google.golang.org/protobuf/proto #6736
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
Conversation
@dfawley I'm not sure I understand the test failing. Could you guide me through it? |
@Clement-Jean another push after |
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 for the PR! One question tho: A quick grep showed the following as the only remaining non .pb.go
usages of github.com/golang/protobuf
.
channelz/service/service_test.go
credentials/credentials.go
internal/pretty/pretty.go
Was the plan to remove the usages in a future PR? The first 2 in the list seem pretty small enough to add to this PR -- which makes us more confident to remove protov1
from pretty/pretty.go
d.CheckValid() already does the nil check Co-authored-by: Arvind Bright <arvind.bright100@gmail.com>
For now, as per @dfawley, the plan is to keep service_test.go as is (issue #5316). This means that credentials.go cannot be updated, and I made the judgment call to keep pretty.go as is because of this. Hope that's ok. Finally, |
Sorry, i should have been more specific. You can also do @Clement-Jean -- could you fix it? @dfawley: Could you please take another look at the changes here? |
channelz/service/func_linux.go
Outdated
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.
Is it possible to revert this directory, please? I'm making some pretty major changes and would like to avoid the conflict unless this is necessary for the rest of the PR.
spb "google.golang.org/genproto/googleapis/rpc/status" | ||
"google.golang.org/grpc/codes" | ||
"google.golang.org/protobuf/proto" |
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.
I believe this causes an API change, right? Now our status package only works with new messages, and breaks with the old ones? IIUC we should be using this instead in WithDetails
and Details
: https://pkg.go.dev/google.golang.org/protobuf/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.
@Clement-Jean This changes the API of WithDetails, because proto.Message
is now different.
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.
@dfawley did you see the tests (status_test.go)? You mean that this isn't enough to prove the API didn't change? If that's not enough maybe I can revert the changes or add more tests to make sure it doesn't break
detail, err := any.UnmarshalNew() | ||
if err != nil { | ||
details = append(details, err) | ||
continue | ||
} | ||
details = append(details, detail.Message) | ||
details = append(details, detail) |
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.
Are these new-style protos compatible with users running with github.com/golang/proto
and ptypes
? If not, we can't make this part of this change.
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.
How would I go about testing this? Should I write a status_test.go
and check that both versions work?
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.
For example, I wrote this:
func (s) TestWithDetailsVersionsCompat(t *testing.T) {
details := []protoreflect.ProtoMessage{
ptypes.TimestampNow(),
ptypes.DurationProto(1 * time.Hour),
×tamppb.Timestamp{},
&durationpb.Duration{},
}
status := New(codes.InvalidArgument, "an error")
if _, err := status.WithDetails(details...); err != nil {
t.Fatalf("unexpected error: %v", err)
}
}
and it passes.
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.
Not sure about how to test DynamicAny though, if you have any idea let me know.
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.
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.
How would I go about testing this? Should I write a status_test.go and check that both versions work?
Yes, that sounds good.
For example, I wrote this [...] and it passes.
This doesn't look like what I was thinking (because it's testing WithDetails
, not Details
), but it's still a useful test. What I had in mind was something that called Details
on a status containing details, and does type assertions using protov1 messages:
st := status.New().WithDetails(ptypes.TimestampNow(), timestamppb.Now()) // Create with old ptypes and new tspb
x := st.Details()[0]
if _, ok := x.(protov1.Message); !ok {
t.Fatal()
}
if _, ok := x.(timestamppb.Timestamp); !ok {
t.Fatalf()
}
I thought that anypb.UnmarshalNew()
produced new protov2.Message
s which were incompatible with old protov1.Message
s. But if the new protov2.Message
is a superset of the old protov1.Message
then I think this should be safe to change, especially because it's returned as any
instead of protov1.Message
.
This PR is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed. |
@dfawley anything left to do? |
Yes; pinged the thread above.. |
This PR is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed. |
@dfawley just checking. I replied in the comments, did you see? |
@Clement-Jean do you still have this change? I didn't see this comment in time. |
@dfawley yes, still have it |
I'll take a look tomorrow! (Sorry for the spam.) |
Wait, something is wrong with github.. It let me click "reopen", but it's still showing closed with the same error. |
I think I accidentally removed the fork from Github, but I still have it locally. I'll clean it up and push it back, it should be ready tomorrow for you. editHere it is: https://github.com/Clement-Jean/grpc-go |
@Clement-Jean It's still not letting me reopen this, though.. Would you mind creating a new PR, please? |
This is the first step of solving the issue #5316
RELEASE NOTES: none