Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider protobuf version pinning on protocols #2690

Open
5A11 opened this issue Feb 17, 2022 · 0 comments
Open

Reconsider protobuf version pinning on protocols #2690

5A11 opened this issue Feb 17, 2022 · 0 comments
Assignees
Milestone

Comments

@5A11
Copy link
Member

5A11 commented Feb 17, 2022

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.
@5A11 5A11 added this to the v1.3.0 milestone Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants