Use betterproto in the plugin #161
Conversation
| """ | ||
| True if proto_field_obj is a OneOf, otherwise False. | ||
|
|
||
| .. warning:: |
There was a problem hiding this comment.
this is referring to monkey_patch_oneof_index
| @@ -139,6 +165,7 @@ def get_comment( | |||
| class ProtoContentBase: | |||
| """Methods common to MessageCompiler, ServiceCompiler and ServiceMethodCompiler.""" | |||
|
|
|||
| source_file: FileDescriptorProto | |||
There was a problem hiding this comment.
turns out tracking the source_file is necessary to ensure we look in the right file to find comments, in case there are multiple source proto files in scope.
| @@ -360,7 +400,7 @@ def betterproto_field_args(self) -> List[str]: | |||
| def field_wraps(self) -> Optional[str]: | |||
| """Returns betterproto wrapped field type or None.""" | |||
| match_wrapper = re.match( | |||
| r"\.google\.protobuf\.(.+)Value", self.proto_obj.type_name | |||
| r"\.google\.protobuf\.(.+)Value$", self.proto_obj.type_name | |||
There was a problem hiding this comment.
this was causing chaos by matching EnumValueDescriptorProto as if it were EnumValue.
2113cbf to
2cc3e05
Compare
|
I've gone through, this all looks fine to me except for the one bit that I left a comment on, but even then it's simply me not understanding how it works. If you want me to go through this more thoroughly I could checkout this branch and play with it for a bit, but if not I'd be keen to get this out the door in the beta release and uncover any small patches that need to be made later. |
|
Fixed the merge conflicts |
This means the betterproto plugin no longer needs to depend durectly on protobuf. This requires a small runtime hack to monkey patch some google types to get around the fact that the compiler uses proto2, but betterproto expects proto3. Also: - regenerate google.protobuf package - fix a regex bug in the logic for determining whether to use a google wrapper type. - fix a bug causing comments to get mixed up when multiple proto files generate code into a single python module
- Remove plugin dependency on protobuf since it's no longer required. - Update poethepoet to for better pyproject toml syntax support - Add handy generate_lib poe task for maintaining generated libs
|
@cetanu I rebased again and got CI tests to pass. I think it would be awesome to get this merged. There a a few other smaller quality improvement PRs waiting behind it. In my mind this is a minor milestone for betterproto's maturity, to not depend on protobuf to compile. It's probably worth checking out and doing whatever is necessary satisfy yourself that it's good. I appreciate you taking the time. |
This means the betterproto plugin no longer needs to depend durectly on protobuf. This requires a small runtime hack to monkey patch some google types to get around the fact that the compiler uses proto2, but betterproto expects proto3. Also: - regenerate google.protobuf package - fix a regex bug in the logic for determining whether to use a google wrapper type. - fix a bug causing comments to get mixed up when multiple proto files generate code into a single python module
This builds on work started for #152, and will make it easier to support custom options. @adriangb
Make plugin use betterproto generated classes internally
This means the betterproto plugin no longer needs to depend directly on
protobuf.
This requires a small runtime hack to monkey patch some google types to
get around the fact that the compiler uses proto2, but betterproto
expects proto3.
Also:
wrapper type.
generate code into a single python module
Update deps & add generate_lib task