search

danielgtaylor / python-betterproto

Clean, modern, Python 3.6+ code generator & library for Protobuf 3 and async gRPC
MIT License
1.51k stars 214 forks source link

Generation without gRPC #44

Open atollk opened 4 years ago

atollk commented 4 years ago

I would like to use betterproto for the generation of code from proto messages but without the usage of gRPC. However, there are still services defined in my .proto files for which I will be generating code with a different plugin. Thus, I need to disable the service generation of the betterproto plugin which, as far as I can tell, is not possible at the moment.

jameslan commented 4 years ago

Why not split them into different .proto files?

I think that would be more intuitive and clear for a potential code maintainer

atollk commented 4 years ago

It seems kind of odd that a protobuf plugin like this would require the user to structure their files in a specific way to be usable.

Besides that, I disagree with your suggestion and feel that 

service FooService {
  rpc GetSomething(FooRequest) returns (FooResponse);
}

for a service like this, having FooRequest and FooResponse in the same file is better than having them separated from FooService.

nat-n commented 4 years ago

The obvious workaround is to remove the code you don't want to from the generated files.

That said I think it does make sense for betterproto to support this kind of use case, and maybe also offer the option for generating grpcio vs grpclib backed gRPC stuff as well.

AFAIK there's no first class way to pass parameters to a protoc plugin, but this could be achieved by factoring out multiple plugin executables, one with gRPC related content and one without.

nat-n commented 4 years ago

Similar issue: https://github.com/danielgtaylor/python-betterproto/issues/20

zbynekwinkler commented 2 years ago

What would it take to have this implemented? I can try to scratch my itch since it would help me lower the number of dependencies since I am not using grpc at all - I believe I could get rid off grpclib, h2, multidict, hpack and hyperframe.

The obvious workaround is to remove the code you don't want to from the generated files.

Just having import betterproto needs to have all the above mentioned dependencies installed so this workaround does seem to be possible.

Gobot1234 commented 2 years ago

The first step for first-party support for this would come from #165 (see --no-generate-services argument) if I can ever get around to fixing the compilation issues I was having with windows and linux. After that, I'm not sure how you can remove some dependencies if an extra (e.g. betterproto[compiler] the extra is compiler) is provided. Currently having things like code generation behind an extra is already a big headache and I can imagine having grpc support off by default would be more of the same.

zbynekwinkler commented 2 years ago

165 seems huge undertaking - not really something an outsider like me can easily help with. However the split (no matter the headache) seems to be worth it to me. I don't mind having everything installed for development. For deployment, there is no need for a compiler - and in my case - neither for the grpc stuff. So if anything, I'll try to cut out grpc in a fork and see what that involves to get and idea about the scale/headache.