Stub structure and Methods will relay on protobuf API V2

[avivbaron]

Hey, since the old protobuf package of google is already deprecated, I was trying to base my code only on the new package(google.golang.org/protobuf) and everything looks fine but since Im using and relaying on your Stub structre and methods which relay on the old package I'm a bit stuck with finding how to replace it appropriately.

Do you have any suggestions on how to replace it correctly or maybe you already working on adapting it to V2 ? :)

Thanks

[jhump]

Do you have any suggestions on how to replace it correctly or maybe you already working on adapting it to V2 ? :)

The README has a blurb at the top talking about this. I am working on a v2, and it's nearly done (https://github.com/jhump/protoreflect/tree/v2).

But, also, as of v1.15, interop between this repo and the protobuf API v2 should work fine. So it should be easy to continue using this repo and also use the new protobuf API v1 support for reflection, descriptors, and dynamic messages.

[avivbaron]

Do you have any suggestions on how to replace it correctly or maybe you already working on adapting it to V2 ? :)

The README has a blurb at the top talking about this. I am working on a v2, and it's nearly done (https://github.com/jhump/protoreflect/tree/v2).

But, also, as of v1.15, interop between this repo and the protobuf API v2 should work fine. So it should be easy to continue using this repo and also use the new protobuf API v1 support for reflection, descriptors, and dynamic messages.

I have an issue with the conversion between V1 message and V2. but i'll try to find a way to fix it. Do you have an estimate of when the new version will be released?

Thanks :)

[jhump]

Do you have an estimate of when the new version will be released?

I had hoped to cut an initial release candidate in 2023 😞

I think the repo is really close. There may be some recent-ish changes on the main branch that I need to cherry-pick or port to the v2 branch, but the functionality and the API and main code I think are all pretty much done. But it needs more test coverage (and inevitably fixes for whatever the new tests uncover). I would like to get it done soon.

[avivbaron]

Hi, Thank you for your detailed answer. Any chance you will be able to provide a kind of early access? Would be very helpful for both of us. I can provide some input about what working and what is not. Thanks

[jhump]

@avivbaron, sure, you can already try it out. There have been no tagged releases on that work-in-progress branch, so you have to pull it in using a commit sha. This would pull in the current head of that branch:

go get github.com/jhump/protoreflect/v2@c9ae7caed596cda2e3c4a90f5973a46081a371a

The package structure is a little different. There is no longer any desc, dynamic, or desc/protoparse at all. (The former two are replaced by functionality in the protobuf API v2; the latter replaced by github.com/bufbuild/protocompile.) All of the other functionality is still present, but moved around a little. For example, desc/protoprint and desc/builder are now protoprint and protobuilder. And dynamic/msgregistry functionality is now a part of the new protoresolve package.

[avivbaron]

Thank you very much :)

[avivbaron]

Hey, I'm using the protoparse.Parser function in my project and I saw that there isn't parser package or function in your new version. can you help me with replacing it correctly?

Thanks :)

[jhump]

@avivbaron, see https://github.com/bufbuild/protocompile?tab=readme-ov-file#migrating-from-protoparse

[avivbaron]

Thanks again for helping me a lot :) After I did those changes I left with "*descriptorpb.FileDescriptorProto" object. How do I get "protoreflect.FileDescriptor" from it?

[jhump]

@avivbaron, sorry, I don't have enough context. What exactly are you doing? Most of the protocompile API is in terms of protoreflect.Descriptor.

[avivbaron]

U r right. it was my mistake. The last thing I got left to do is to find out how to fill "dependencies" in linker.Link() while the result object the i get from "parser.ResultFromAST()", result.FileDescriptorProto().Dependency returns []string instead of []linker.Files

[jhump]

@avivbaron, why are you calling the linker directly? What is it you are doing that prevents you from using the main protocompile.Compiler? The root compiler package handles all of the steps. The sub-packages are only meant to be used if you are doing something custom, such as parsing without linking.

[avivbaron]

Thanks a lot! I'm done with the migration to the new protobuf modules all thanks to you :)

[Shnitzelil]

Hi, Any official release for V2?

[jhump]

@Shnitzelil, I'm afraid not. I've hit some snags in the way v2 of the repo wants to decorate instances of protoreflect.Descriptor. While the v2 branch is close to ready for release as far as features and quality, these snags may mean I need to re-write parts of it to avoid future disasters regarding compatibility with future protobuf-go releases.

The main issue is whether the protobuf-go project will continue to allow external implementations of the descriptor interfaces in the future. While the v2 branch works just fine today, the current maintainers of protobuf-go are considering changing that -- having their internal code be able to type-assert to their internal concrete implementations. That means nothing outside the package would be able to implement the interface (without risk of type-assertion panics); that would break stuff in my v2 branch, which provides wrappers/decorators that embed their instances. I'm still working with them to see the direction they'll take. But, unfortunately, chances are good that the direction will mean I need to make a good bit of changes to the v2 branch. Once that all settles, only then can I provide a release. Sorry for the delays.