> The core of this crate is a python2 script codegen.py that is provided to the protobuf compiler, protoc as a plugin.
That's... surprisingly janky. Not only Python tooling is always painful to deal with (compared to Go/Rust/...), but Python 2? And in a project that otherwise has no reason to depend on Python? :(
In comparison, the Go protoc plugin is written in Go, the alternatice rust-protobuf protoc plugin is witten in Rust, the Typescript one is written in Typescript...
See issues https://github.com/dropbox/pb-jelly/issues/37 and https://github.com/dropbox/pb-jelly/issues/40 for context.
My $dayjob also started as a large python code base, and so there are still lots of one-off Py2 scripts that need to be deleted or rewritten.
So they're maintaining a project with two languages with Python 2 as a hard requirement for code generation? Oh dear.
This tells me that this project will have the same fate as djinni [0] or their similar archived projects.
protoc plugins have an interesting bootstrapping problem as well: the protoc-gen-$LANG interface requires the ability to ser/de protobuf messages that describe the proto file's AST. If your build system builds almost everything from scratch, including the protoc plugin, this means that you need to have a variant of your protoc plugin linked to a working proto implementation...
That's not to say this is impossible or even difficult, but at the time that I last looked at it (more than a year ago at this point), it made it fairly unpalatable to move the codegen from Python to Rust.