prefer gpb to elixir-protobuf/protobuf
the-mikedavis opened this issue · comments
According to hex.pm, the status of protobuf projects is roughly
| package | recent downloads | notes |
|---|---|---|
tomas-abrahamsson/gpb |
436_657 | primarily targets erlang fwict |
elixir-protobuf/protobuf |
223_097 | name collision with below |
bitwalker/exprotobuf |
58_526 | name collision with above |
ahamez/protox |
4_627 | requires protoc installed on compilation machine |
Currently spear uses elixir-protobuf/protobuf, but this causes incompatibility with any project that uses bitwalker's implementation, including exponentially/extreme. For use in a service/application, I wouldn't mind just choosing either but since this is a library we need to be as dependency-permissive as possible.
So because of the module conflicts, I consider both elixir-protobuf/protobuf and bitwalker/exprotobuf non-starters.
Similarly I'm not comfortable adding installation instructions for protoc to this library (required for compiling protox definitions). Acceptable in a service/application but this library should bite the bullet of (com/trans)piling .proto files into an elixir/erlang format.
Ideally I'd like to write two separate libraries: a parser/transpiler for proto into elixir/erlang terms and then a protobuf engine which performs the encoding/decoding. That way libraries can use the transpiler to generate some files and then only export a dependency on the engine.
However, I only have so much time and energy I realize that with my strong opinions about what is right and wrong library behavior I am poking the library version of this XKCD bear:
:gpb seems to be the only good option currently. It isn't completely ideal (e.g. it fails to install with 🤦 I have a PR open in gpb to fix this) but I might need to just pick my poison and move on.Mix.install/1
from a quick check in a sandbox it appears as though :gpb will be a usable option
it's all erlang records which is kinda awkward to deal with in Elixir but Spear should be abstracting away the need to deal with those low-level datastructures anyways