> 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...
> 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...
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.
another former contributor to pb-jelly, though no longer at Dropbox.
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.
> 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...