Ruby gRPC client generation should be merged into gapic pipeline

[googleapis]

Ruby gRPC client generation should be merged into gapic pipeline

[bjwatson]

Does this mean that the GapicClientPipeline would also do the work of GrpcClientPipeline when --language=ruby? Why should this be different for Ruby vs. other languages?

The pipeline that does the packaging can be distinct from the pipelines that do the gRPC and GAX generation. That way the two generation steps can remain separate, and then be brought together for the package.

For the gRPC generation, I think @geigerj discovered that it's best to use grpcio-tools for Python, rather than protoc. Can you elaborate @geigerj?

[geigerj]

On grpcio-tools: Currently we get protoc from linuxbrew here: https://github.com/grpc/homebrew-grpc

That site indicates that the linuxbrew method is deprecated for all languages except C/C++. For Python, the replacement is the grpcio-tools package on PyPI, which includes an executable replacement for protoc that pulls in the Python plugin automatically. (Although I haven't gotten this to work, see grpc/grpc#7857). Presumably there is also a replacement for ruby.

In Python, this is especially necessary because the plugin installed by the linuxbrew formula produces codegen that is only compatible with the beta version of the grpc runtime library, not the 1.0 version.

[geigerj]

Also agreed with Brian that the difference between Ruby and other languages seems strange -- why can't we just configure the output directory for both pipelines be the same, while keeping the actual implementations separate? This would permit consistency with other languages, both in the invocation of the pipeline, and in the way we structure output for non-cloud APIs.

[jmuk]

There is also grpc-tools Ruby package (see https://rubygems.org/gems/grpc-tools). If that's the way to go, let's use this (i.e. adding to the Dockerfile).

[jmuk]

Having the same output directory (but keeping the separation of the pipeline) would be good enough. One concern is that, that way the instruction for remote pipeline (i.e. self-service) will require a manual step to merge them into a single package, like:

1. run GrpcClientPipeline, then download artifacts
2. run GapicClientPipeline, then download artifacts
3. copy the result of 1 into the result of 2
   (4. build the .gem file)

[geigerj]

I think the copy-and-build step is actually consistent with the current instructions for Java. The artman wrapper will also eventually provide a single command (called "generateLibrary" or similar) that runs both pipelines and downloads the combined result.

[jmuk]

Okay, if that's consistent with others, that's totally fine.
Let me close this issue by itself. I'll file another issue for the use of its own grpc-tools.