4 ms·

From pb-jelly-gen: > The core of this crate is a python2 script codegen.py that is provided to the protobuf compiler, protoc as a plugin. That's... surprising

by q3k 6y ago

From pb-jelly-gen: > 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...

eggsnbacon1 6y ago
this might be one of those projects that gets open sourced with the hope that someone else will maintain it
cbhl 6y ago
The very first prototypes of Dropbox were Py2, so I suspect that legacy is a reason why it was chosen for the codegen. 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.
rvz 6y ago
> 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. [0] https://github.com/dropbox/djinni https://github.com/dropbox/djinni
nipunn1313 6y ago
Hi! One of the authors here. This was an oversight in the documentation. The codegen is py2 and py3 compatible. Fixed! See issues https://github.com/dropbox/pb-jelly/issues/37 https://github.com/dropbox/pb-jelly/issues/37 and https://github.com/dropbox/pb-jelly/issues/40 https://github.com/dropbox/pb-jelly/issues/40 for context.
rbtying 6y ago
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.

by q3k 6y ago

eggsnbacon1 6y ago

this might be one of those projects that gets open sourced with the hope that someone else will maintain it

cbhl 6y ago

The very first prototypes of Dropbox were Py2, so I suspect that legacy is a reason why it was chosen for the codegen. 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.

rvz 6y ago

> 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. [0] https://github.com/dropbox/djinni https://github.com/dropbox/djinni

nipunn1313 6y ago

Hi! One of the authors here. This was an oversight in the documentation. The codegen is py2 and py3 compatible. Fixed! See issues https://github.com/dropbox/pb-jelly/issues/37 https://github.com/dropbox/pb-jelly/issues/37 and https://github.com/dropbox/pb-jelly/issues/40 https://github.com/dropbox/pb-jelly/issues/40 for context.

rbtying 6y ago

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.