Vendor ocaml-protoc-plugin as a git subtree

[wokalski]

Why?

The main repo sees very little activity and maintenance. There are some unanswered issues and unmerged pull requests there.

Solution

I believe we should vendor ocaml-protoc-plugin in a git subtree (+ possibly publish it as ocaml-protoc-plugin-grpc).

The reason for a subtree is to make it easy to either split it into a separate repo or upstream the changes to issuu/ocaml-protoc-plugin in the future.

An alternative

We could obtain maintain access to https://github.com/issuu/ocaml-protoc-plugin. If we are given access I would like to enforce our open source policies there though; the main one is: every contributor that gets their PR accepted gets write access to the repo[1]. I've been quite successful in the past at keeping my open source projects healthy even after I lost interest in them. I attribute it to this policy. Do you think it's possible @andersfugmann?

1: the exception being "typo" fixes that might be automated or spammy.

Which solution should we pursue?

I believe in doing things fast - I think we should indeed create a subtree and vendor the repo and then when/if we are given a green light from issuu to maintain the upstream, we can remove the vendored version.

[quernd]

Note that it's only an optional dependency of ocaml-grpc (you could use other protobuf libraries or no protobuf at all).

That being said, I agree that the repo has seen very little activity recently, and some forks offer enhancements that make it possible to add an opinionated way of making typesafe gRPC calls with minimum boilerplate. E.g. this unmerged PR parses service/method name.decoders/encoders and packages it up in a module together with the decoders/encoders. I also have a some more quality of life enhancements here and here.

[wokalski]

I added a "good first issue" label to this. It's not a good first issue for an OCaml newbie but for someone moderately familiar with OCaml it should be pretty straightforward: add ocaml-protoc upstream as a subtree here, and then create PR(s) with the quality of life improvements @quernd mentioned.

[bobot]

FWIW I used a submodule instead of a subtree in https://github.com/ryjones/fabric-chaincode-ocaml

[tmcgilchrist]

issuu/ocaml-protoc-plugin#28 parses service/method name.decoders/encoders and packages it up in a module together with the decoders/encoders

That PR has been merged since and released with ocaml-protoc-plugin.4.4.0 on opam. Do the other linked quality of life improvements still make sense @quernd ? Are there other improvements that could be packaged up as PRs to ocaml-protoc-plugin?

[quernd]

Thanks for bringing this up! I'm going to rebase our fork and see how much is left and whether it makes sense to propose upstream.

[tmcgilchrist]

This is perhaps not required as vendored if we get the required changes into the next version of ocaml-protoc-plugin. Pending a decision on naming generated fields on issuu/ocaml-protoc-plugin#49 this should be closable soon.

[andersfugmann]

I've merged issuu/ocaml-protoc-plugin#50 which adds extra fields to the generated service struct which should allow you to implement generic functions as discussed in issuu/ocaml-protoc-plugin#49.

The changes are included in release 4.5.0, which is on its way into in opam repository (ocaml/opam-repository#23936).

[tmcgilchrist]

I'm working on updating the examples to use the new API. Thanks @andersfugmann