Reconsider protobuf version pinning on protocols
5A11 opened this issue · 0 comments
5A11 commented
Is your feature request related to a problem? Please describe.
Pinning the Protobuf compiler version on protocols creates problems when other libraries (e.g. cosmpy) require updating the protobuf library. This means all protocols must be regenerated with the new protobuf version and the new version pinned.
The protobuf compiler version is pinned to avoid different developers generating all protocols using different versions of the protobuf compiler, each resulting to slightly modified "pb2" files creating messy commits.
Describe the solution you'd like
One idea would be to reconsider what goes in a protocol package:
- we could exclude the "_pb2" file from protocol packages, leaving that to be generated locally on particular machines. This means we don't have to pin the protobuf version on protocols anymore, or define that to be a range (e.g. >3 and <4).
- we could exclude everything except the protocol specification. This is in line with what the whole model is about, having the specification define a protocol independent of specific tech, and leave machines generate the protocols locally. The problem would be custom types which then would not be shareable and other files (esp. messages, dialogues) which could be modified but not shareable. A solution to this would then be, include the specification and any file one wants, and let the other be generated locally on different machines. This way everything is interpreted locally but also anything that is modified (e.g. messages.py) and esp. custom types can be shared.