Generation without gRPC about python-betterproto

[atollk]

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.

[jameslan]

Why not split them into different .proto files?

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

[nat-n]

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]

Similar issue: #20

[zwn]

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]

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.

[zwn]

#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.