-
Notifications
You must be signed in to change notification settings - Fork 53
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
another starlark / proto binding #23
Comments
Thanks! I was planning to upstream some of the Protobuf code from Skycfg into upstream once the go-protobuf reflection API landed, but it looks like that won't be necessary. How stabilized is your API? There are a couple parts of it that are a bit awkward to work with in the context of config data, which is why Skycfg diverges. If possible, I would love to resolve the API differences in favor of a single unified Specifically:
[0] Skycfg would need some hooks to handle weird bits of Kubernetes' pseudo-protos. |
I've copied the API of the package below; as you can see, it's pretty straightforward. (descpool is Google's internal descriptor pool.)
Yes, you need to use proto.has(msg, "fieldname"). Sorry I didn't show that in the example, but it's part of the Starlark module, along with {,un}marshal{,_text}.
A proto field is either a scalar, a list (RepeatedField), or a reference to a message. Assigning to a scalar field is trivial. Assigning an iterable to a repeated field causes allocation of a new RepeatedField value and a check that each element of the iterable can be assigned to T. Assigning to an element of a repeated field causes an array element update; RepeatedFields are basically mutable lists of a particular element type. Assigning to a message field x.f=y field causes x.f to alias y. Mutations to one will be observed by the other.
Yes, strings, numbers and EnumValueDesciptor values can all be assigned directly to enum-typed message fields.
|
@alandonovan, any update on this issue? I see that work seems to be progressing on golang/protobuf#364. Is everything on track for open-sourcing your starlark/protobuf bindings? Also, I assume that those bindings will be dynamic (ie. based on descriptors, not on Golang reflection against the generated protobuf code). Could you please confirm that this is correct? Thanks! |
I've started to look at applying these API bindings here: https://github.com/afking/starlarkproto . Only have basic message construction but will update to support the full API soon. |
@emcfarlane Thanks! Do you use it somewhere? @alandonovan Any plans/chance that such bindings be available for Bazel? |
This change defines an optional Starlark module for encoding and decoding protocol buffers (https://developers.google.com/protocol-buffers/). It adds a dependency on google.golang.org/protobuf. Fixes #309 Updates stripe/skycfg#23 Change-Id: If233439fffe06ac71af6c5f3655cb19f7bec9f5a
This change defines an optional Starlark module for encoding and decoding protocol buffers (https://developers.google.com/protocol-buffers/). It adds a dependency on google.golang.org/protobuf. No promises of API stability yet: there are a number of TODOs to be resolved and questions to be answered first, but I would like to get this into the hands of the community. See discussion in stripe/skycfg#23. Fixes #309 Change-Id: I0b46b3aeed7d3675ffa77dfbd4a6ac56612a98dd
This change defines an optional Starlark module for encoding and decoding protocol buffers (https://developers.google.com/protocol-buffers/). It adds a dependency on google.golang.org/protobuf. No promises of API stability yet: there are a number of TODOs to be resolved and questions to be answered first, but I would like to get this into the hands of the community. See discussion in stripe/skycfg#23. Fixes #309 Change-Id: I0b46b3aeed7d3675ffa77dfbd4a6ac56612a98dd
This change defines an optional Starlark module for encoding and decoding protocol buffers (https://developers.google.com/protocol-buffers/). It adds a dependency on google.golang.org/protobuf. No promises of API stability yet: there are a number of TODOs to be resolved and questions to be answered first, but I would like to get this into the hands of the community. See discussion in stripe/skycfg#23. Fixes #309 Change-Id: I2f74e266dc2c6b7da34eb0a9414f583105a0852c
This change defines an optional Starlark module for encoding and decoding protocol buffers (https://developers.google.com/protocol-buffers/). It adds a dependency on google.golang.org/protobuf. No promises of API stability yet: there are a number of TODOs to be resolved and questions to be answered first, but I would like to get this into the hands of the community. See discussion in stripe/skycfg#23. Fixes #309 Change-Id: I078be4aa8d3c299a59251c3f3e366f1334de9e4b
This change defines an optional Starlark module for encoding and decoding protocol buffers (https://developers.google.com/protocol-buffers/). It adds a dependency on google.golang.org/protobuf. No promises of API stability yet: there are a number of TODOs to be resolved and questions to be answered first, but I would like to get this into the hands of the community. See discussion in stripe/skycfg#23. Fixes #309
FWIW, the starlarkproto package was committed to go.starlark.net back in November: google/starlark-go#318 If there's something that it should support, but does not, please open an issue at go.starlark.net. |
Hi, author of go.starlark.net here. Just wanted to let you know that I have an implementation of Starlark support for protocol messages that we use inside Google. It presents a slightly different API that what you have in skycfg. See the example below for comparison.
I haven't open-sourced it yet because it depends on Google's internal implementation of dynamic message and message reflection. The Go protobuf team is hard at work adding support for these features to the open-source proto.Message API (golang/protobuf#364). Once that's done I will port our starlarkproto package to use it and then make it available.
proto:
Starlark:
The text was updated successfully, but these errors were encountered: