Expose compilerlib library publicly?

[Lupus]

I am working on some proprietary code generator for Twirp and was able to implement it successfully using this protobuf implementation for OCaml, but I had to vendor the library and mark compilerlib as a public library to be able to do so. Would be nice if compiler library was public, it's quite useful for developing protobuf related tooling.

[c-cube]

I don't suppose we can convince you to open source the Twirp code generator and contribute it? :-)

[c-cube]

could you try with this branch: expose-compiler-libs ?

[Lupus]

I don't suppose we can convince you to open source the Twirp code generator and contribute it? :-)

Well, our Twirp generator targets our in-house http framework, which we brewed long time before Dream appeared, so it's pretty optinionated and it does not make much sense to open-source neither it, nor the Twirp generator itself. Actually it took me 2 days to create a generator on top of ocaml-protoc, just hacked the executable part to produce 2 extra files with our specific content and wrote the runtime library to handle Twirp errors and co. Protocol itself is tiny and transport agnostic, which makes it really attractive. The most challenging part is JSON encoding, which is rarely supported by protobuf compilers. Twirp allows to use JSON encoding as a first class thing, so it's a must to implement. Luckily ocaml-protoc has that implemented out of the box, only a switch on Content-Encoding header was left to be implemented in the runtime lib 😊

[c-cube]

Heh, was worth trying :). Let me know if this is convenient for you!

[Lupus]

could you try with this branch: expose-compiler-libs ?

I've glanced at the PR, looks great! Thanks! I've looked at what bits I had to replicate in the hacked binary part of my generator - code to produce names of varous OCaml entities:

• Pb_codegen_backend.field_name
• Pb_codegen_backend.module_name
• Pb_codegen_backend.type_name

Would be cool to have those exported in corresponding .mli file. I have to refer to types produced by ocaml-protoc to be able to generate code, that uses those types... Do you think it's sensible to expose those functions?

[c-cube]

pushing some of them in an Internal submodule. Let me know if others are needed?

[Lupus]

Awesome! ❤️
Looks like these are the only ones I depend on so far. This would greatly reduce the forked binary footprint! Actually I could even use original ocaml-protoc executable for generation of protobuf encoding, and leave only twirp generation in my executable without any copy-paste 👍

[Lupus]

Thanks a lot for your help! Appreciated.