Consider deprecating go protoc plugin in favor of protoc-gen-twirp_ruby gem

[darronschall]

Hello!

We ❤️ Twirp at Collective Idea. We wrote it about it using our protoc-gen-twirp_ruby gem at https://collectiveidea.com/blog/archives/2024/07/24/generating-twirp-ruby-protobuf-integration-using-ruby in hopes of making it easier for Rubyists to integrate Twirp-Ruby in their projects. It's also why we opened the discussion at #114 for additional maintainers.

Given that there hasn't been much movement on open PRs for the go module, and for various other reasons discussed in our article, we were wondering if you'd be open to deprecating the go module moving forward?

We're happy to help coordinate this change for updating documentation, cleaning up stale issues, updating the wiki, etc...

[arthurnn]

@darronschall ❤ this is an interesting idea.

We had issues in the past, where we made a broken change to the Ruby library, and attempt to fix release a v2 version, but publishing a v2 go package requires a more serious update in apps (change imports). Therefor we yanked that.

On v1.10.x we made the decision into de-coupling the go and ruby versions for that particular reason, as doing major changes in ruby, should not need a bump into the go toolchain.
What we lost there, was the simplicity of making client and server follow the same version.
I am afraid that if protoc-gen-twirp_ruby gem is another dependency, we would now have yet another layer of dependency where things could get out of sync. i.e.: a new change to the protoc(client) and needing a matching server side change.

A solution, would be to bring both to this project, however, I haven't thought too much in the logistics of it. Also I would like to experiment first, at GitHub, transitioning to the gem, instead, and see how our automatons would behave, and the amount of extra work needed.

Thanks for the message.

[darronschall]

Also I would like to experiment first, at GitHub, transitioning to the gem, instead, and see how our automatons would behave, and the amount of extra work needed.

Let us know how it goes! Migration is straightforward; in most cases it shouldn't even require any downstream changes. We included a small section on migration in the README.

If you run into any issues, we'll be happy to address them and add additional specs as necessary to our test suite.

A solution, would be to bring both to this project

I don't have experience shipping multiple gems in a single repository. My preference is to keep them separate, on separate release cycles. For example, we may add additional options to the generator that don't necessitate changing twirp-ruby itself. I think it does make sense to at least sync on major version numbers.

Collective Idea, in general, has a proven track record of being good open source stewards. We're committed to twirp-ruby and our plugin, and would quickly work to resolve any breaking changes in the plugin generated output as twirp-ruby evolves.

[shawnHartsell]

On v1.10.x we made the decision into de-coupling the go and ruby versions for that particular reason, as doing major changes in ruby, should not need a bump into the go toolchain. What we lost there, was the simplicity of making client and server follow the same version. I am afraid that if protoc-gen-twirp_ruby gem is another dependency, we would now have yet another layer of dependency where things could get out of sync. i.e.: a new change to the protoc(client) and needing a matching server side change.

👋 I'm part of the API team here at GitHub and just wanted to re-emphasize the above. Having separate versioning and release cycles between the plugin and runtime is very valuable. Additionally, I'm +1 on the external dependency concerns due to the version compatibility requirements between protoc/google-protobuf gem and the Twirp plugin and runtime. It's nice to be able to quickly test upgrades to protoc against the Twirp plugin and runtime all in the same project.

Also I would like to experiment first, at GitHub, transitioning to the gem, instead, and see how our automatons would behave, and the amount of extra work needed.

We're actually in the in the process of improving our Twirp build pipelines so there's def an opportunity for collaboration if this is an avenue you think is worth pursuing.

[skatkov]

This is very exciting to read.

Our company is interested in improving our twirp API workflow as well.

We're not as big as Github, more of humble startup with good open source practices, but if there is anything we can test on our build pipeline - I'll be happy to give it a spin.