Make robust against field removal in grpc protocol about starlink-grpc-tools HOT 2 CLOSED

Before I forget again:

I did look into option 2 noted above, and just as I have the last several times I looked into such, I concluded that it'd be technically possible, but not worth it at this point. As far as I can tell, there is code that could be called for serializing and deserializing raw protobuf messages, but it is in an internal package, so directly using it would be subject to breakage as that package gets updated. On top of that, that is in the pure Python implementation, so using it would mean losing the performance benefit of the native code versions. As an alternative, it should be possible to build descriptors for the messages dynamically, and then just run those through the same process as yagrc uses to create the message classes. There's another problem here, though: there are a couple cases where the strings used for some fields are taken from the reflected protocol data, because SpaceX periodically adds things, and I really don't want to go back to having to update the starlink_grpc module to support every new new alert type or outage reason.

Meanwhile, I believe option 1 will not be so messy as I was thinking, so I guess I'll just stop whining about it and go with that option.

from starlink-grpc-tools.

Those changes should be sufficient for anything that uses the core module (starlink_grpc).

The only significant script that does not use that module is dish_control.py. I may switch that over to use the core module now that it actually has some (minimal) value add for those grpc requests, but if the protocol changes on them, the related functionality is just going to stop working, anyway.

from starlink-grpc-tools.