-
Notifications
You must be signed in to change notification settings - Fork 171
cue: proto support #5
Comments
A Builder parses a collection of .proto file and organizes them according to a CUE package layout. The exising Parse function is expressed in this new API. Issue #5 Change-Id: I980e7654d2b666dd1c637ad6d80f513096907a0b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/2364 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
This often makes sense to do, but it shouldn't be the default. Issue #5 Change-Id: I9f05ac9ee8a770489e7885da9c82790f091aee8b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/2372 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Issue #5 Change-Id: Icb6e8b5c6c490ea7123e554a9fb86a2b8d8ba624 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/2373 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
(at least not yet) Issue #5 Change-Id: If8430cf8ec9bb376bcf0c69ec385f1f0d066c4e6 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/2374 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
What's the status of encoding Cue values as Protobuf? |
It is not implemented so far. Should be straightforward, but stabilizing the new evaluator has priority. But open to contributions. |
In case you're not aware, the new protobuf module has low-level primitive packages for encoding and decoding, for example for arbitrary data in protowire: https://pkg.go.dev/google.golang.org/protobuf@v1.26.0/encoding/protowire https://pkg.go.dev/google.golang.org/protobuf@v1.26.0/encoding/prototext is message-based instead of token-based, though, so it's unclear if you could use it at all without a schema. |
The parseArgs code had some pretty complicated logic. This now separates out the cases for normal instances and user-selected files to avoid at least one level of comingling. The goal of this refactoring is to ultimately allow schema and value files to be separated early on, which, in turn, will allow schema values to be computed early. Such schema will then allow value formats to be interpreted by the type of which they will ultimately land in CUE. This is necessary to parse protobuf, which cannot be parsed without a schema. Issue #5 Change-Id: I2046948a8cf9bc5425ed437247dc89416d0fff76
This will allow schema information to be used for the parsing of values. Issue #5 Change-Id: I7ab2bfb56666ba392b19274bae59da0152e16d9a
The idea here is as follows: When unifying a bag of CUE and non-CUE, CUE can function as a template for non-CUE. For instance, an `int` CUE field could allow JSON string to be interpreted as a number (as is the case for Protobuf). Note that for Protobuf this is imperative, as a proto buffers cannot be parsed without a schema. Issue #5 Change-Id: I9a70c2e8489e6f7f3c26ee90c2fdb1d65ab6e473
This allows the schema with which data files will be merged before they are parsed. This is necessary to support protobuf parsing, including Protobuf / JSON mappings. The usage of this property will be done in a followup CL. Issue #5 Change-Id: I54b8826070217bd3d4e61d7d6f5b692f33553b12
The parseArgs code had some pretty complicated logic. This now separates out the cases for normal instances and user-selected files to avoid at least one level of comingling. The goal of this refactoring is to ultimately allow schema and value files to be separated early on, which, in turn, will allow schema values to be computed early. Such schema will then allow value formats to be interpreted by the type of which they will ultimately land in CUE. This is necessary to parse protobuf, which cannot be parsed without a schema. Issue #5 Change-Id: I2046948a8cf9bc5425ed437247dc89416d0fff76
This will allow schema information to be used for the parsing of values. Issue #5 Change-Id: I7ab2bfb56666ba392b19274bae59da0152e16d9a
The idea here is as follows: When unifying a bag of CUE and non-CUE, CUE can function as a template for non-CUE. For instance, an `int` CUE field could allow JSON string to be interpreted as a number (as is the case for Protobuf). Note that for Protobuf this is imperative, as a proto buffers cannot be parsed without a schema. Issue #5 Change-Id: I9a70c2e8489e6f7f3c26ee90c2fdb1d65ab6e473
This allows the schema with which data files will be merged before they are parsed. This is necessary to support protobuf parsing, including Protobuf / JSON mappings. The usage of this property will be done in a followup CL. Issue #5 Change-Id: I54b8826070217bd3d4e61d7d6f5b692f33553b12
This simplifies the transition to extracting schema for dynamic context. Issue #5 Change-Id: I3848a7f18f13aacaf989c889f22ea8cfde66ee5f
The parseArgs code had some pretty complicated logic. This now separates out the cases for normal instances and user-selected files to avoid at least one level of comingling. The goal of this refactoring is to ultimately allow schema and value files to be separated early on, which, in turn, will allow schema values to be computed early. Such schema will then allow value formats to be interpreted by the type of which they will ultimately land in CUE. This is necessary to parse protobuf, which cannot be parsed without a schema. Issue #5 Change-Id: I2046948a8cf9bc5425ed437247dc89416d0fff76
This will allow schema information to be used for the parsing of values. Issue #5 Change-Id: I7ab2bfb56666ba392b19274bae59da0152e16d9a
The idea here is as follows: When unifying a bag of CUE and non-CUE, CUE can function as a template for non-CUE. For instance, an `int` CUE field could allow JSON string to be interpreted as a number (as is the case for Protobuf). Note that for Protobuf this is imperative, as a proto buffers cannot be parsed without a schema. Issue #5 Change-Id: I9a70c2e8489e6f7f3c26ee90c2fdb1d65ab6e473
This allows the schema with which data files will be merged before they are parsed. This is necessary to support protobuf parsing, including Protobuf / JSON mappings. The usage of this property will be done in a followup CL. Issue #5 Change-Id: I54b8826070217bd3d4e61d7d6f5b692f33553b12
This simplifies the transition to extracting schema for dynamic context. Issue #5 Change-Id: I3848a7f18f13aacaf989c889f22ea8cfde66ee5f
This significanty simplifies finding the right mapping from CUE to protobuf. Also changed map type from map<A,B> to map[A]B. The former caused issues as the comma caused it to be a separate attribute argument (<> is not matched). Encosing it in quotes was also annoying. We considered using [A]:B, but using the map notation allows for more extendibility and less ambiguity in case we must support lists for some reason. This is a backwards incompatible change. Issue #5 Change-Id: Ief64d0c91d481fd7b03a4a8842faf377fd364a26
Note that this is incredibly buggy. Not much I can do, as there just doesn't seem to be any good textproto parser for Go, and this one is the recommended "gold standard". Issue #5 Change-Id: Ieab0910dc4ea6072d9dc50e2947d8a7fb33ba7ef
The parseArgs code had some pretty complicated logic. This now separates out the cases for normal instances and user-selected files to avoid at least one level of comingling. The goal of this refactoring is to ultimately allow schema and value files to be separated early on, which, in turn, will allow schema values to be computed early. Such schema will then allow value formats to be interpreted by the type of which they will ultimately land in CUE. This is necessary to parse protobuf, which cannot be parsed without a schema. Issue #5 Change-Id: I2046948a8cf9bc5425ed437247dc89416d0fff76 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9304 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>
This will allow schema information to be used for the parsing of values. Issue #5 Change-Id: I7ab2bfb56666ba392b19274bae59da0152e16d9a Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9305 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com>
The idea here is as follows: When unifying a bag of CUE and non-CUE, CUE can function as a template for non-CUE. For instance, an `int` CUE field could allow JSON string to be interpreted as a number (as is the case for Protobuf). Note that for Protobuf this is imperative, as a proto buffers cannot be parsed without a schema. Issue #5 Change-Id: I9a70c2e8489e6f7f3c26ee90c2fdb1d65ab6e473 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9321 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
This allows the schema with which data files will be merged before they are parsed. This is necessary to support protobuf parsing, including Protobuf / JSON mappings. The usage of this property will be done in a followup CL. Issue #5 Change-Id: I54b8826070217bd3d4e61d7d6f5b692f33553b12
This simplifies the transition to extracting schema for dynamic context. Issue #5 Change-Id: I3848a7f18f13aacaf989c889f22ea8cfde66ee5f
This significanty simplifies finding the right mapping from CUE to protobuf. Also changed map type from map<A,B> to map[A]B. The former caused issues as the comma caused it to be a separate attribute argument (<> is not matched). Encosing it in quotes was also annoying. We considered using [A]:B, but using the map notation allows for more extendibility and less ambiguity in case we must support lists for some reason. This is a backwards incompatible change. Issue #5 Change-Id: Ief64d0c91d481fd7b03a4a8842faf377fd364a26
Note that this is incredibly buggy. Not much I can do, as there just doesn't seem to be any good textproto parser for Go, and this one is the recommended "gold standard". Issue #5 Change-Id: Ieab0910dc4ea6072d9dc50e2947d8a7fb33ba7ef
Doesn't really copy positioning and all comments, but the textproto API is sort of hit or miss anyway whether this information is supported at all. So good enough for now. Issue #5 Change-Id: Ia0d09a0c4b92756f68c2a09a114311b363fef33a
Note that this is incredibly buggy. Not much I can do, as there just doesn't seem to be any good textproto parser for Go, and this one is the recommended "gold standard". Issue #5 Change-Id: Ieab0910dc4ea6072d9dc50e2947d8a7fb33ba7ef
Doesn't really copy positioning and all comments, but the textproto API is sort of hit or miss anyway whether this information is supported at all. So good enough for now. Issue #5 Change-Id: Ia0d09a0c4b92756f68c2a09a114311b363fef33a
This allows the schema with which data files will be merged before they are parsed. This is necessary to support protobuf parsing, including Protobuf / JSON mappings. The usage of this property will be done in a followup CL. Issue #5 Change-Id: I54b8826070217bd3d4e61d7d6f5b692f33553b12
This simplifies the transition to extracting schema for dynamic context. Issue #5 Change-Id: I3848a7f18f13aacaf989c889f22ea8cfde66ee5f
This allows the schema with which data files will be merged before they are parsed. This is necessary to support protobuf parsing, including Protobuf / JSON mappings. The usage of this property will be done in a followup CL. Issue #5 Change-Id: I54b8826070217bd3d4e61d7d6f5b692f33553b12 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9322 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
This simplifies the transition to extracting schema for dynamic context. Issue #5 Change-Id: I3848a7f18f13aacaf989c889f22ea8cfde66ee5f Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9350 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
This significanty simplifies finding the right mapping from CUE to protobuf. Also changed map type from map<A,B> to map[A]B. The former caused issues as the comma caused it to be a separate attribute argument (<> is not matched). Encosing it in quotes was also annoying. We considered using [A]:B, but using the map notation allows for more extendibility and less ambiguity in case we must support lists for some reason. This is a backwards incompatible change. Issue #5 Change-Id: Ief64d0c91d481fd7b03a4a8842faf377fd364a26
This significanty simplifies finding the right mapping from CUE to protobuf. Also changed map type from map<A,B> to map[A]B. The former caused issues as the comma caused it to be a separate attribute argument (<> is not matched). Encosing it in quotes was also annoying. We considered using [A]:B, but using the map notation allows for more extendibility and less ambiguity in case we must support lists for some reason. This is a backwards incompatible change. Issue #5 Change-Id: Ief64d0c91d481fd7b03a4a8842faf377fd364a26
Note that this is incredibly buggy. Not much I can do, as there just doesn't seem to be any good textproto parser for Go, and this one is the recommended "gold standard". Issue #5 Change-Id: Ieab0910dc4ea6072d9dc50e2947d8a7fb33ba7ef
This significanty simplifies finding the right mapping from CUE to protobuf. Also changed map type from map<A,B> to map[A]B. The former caused issues as the comma caused it to be a separate attribute argument (<> is not matched). Encosing it in quotes was also annoying. We considered using [A]:B, but using the map notation allows for more extendibility and less ambiguity in case we must support lists for some reason. This is a backwards incompatible change. Issue #5 Change-Id: Ief64d0c91d481fd7b03a4a8842faf377fd364a26 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9368 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
Doesn't really copy positioning and all comments, but the textproto API is sort of hit or miss anyway whether this information is supported at all. So good enough for now. Issue #5 Change-Id: Ia0d09a0c4b92756f68c2a09a114311b363fef33a
Note that this is incredibly buggy. Not much I can do, as there just doesn't seem to be any good textproto parser for Go, and this one is the recommended "gold standard". Issue #5 Change-Id: Ieab0910dc4ea6072d9dc50e2947d8a7fb33ba7ef
Doesn't really copy positioning and all comments, but the textproto API is sort of hit or miss anyway whether this information is supported at all. So good enough for now. Issue #5 Change-Id: Ia0d09a0c4b92756f68c2a09a114311b363fef33a
Note that this is incredibly buggy. Not much I can do, as there just doesn't seem to be any good textproto parser for Go, and this one is the recommended "gold standard". Issue #5 Change-Id: Ieab0910dc4ea6072d9dc50e2947d8a7fb33ba7ef Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9369 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Doesn't really copy positioning and all comments, but the textproto API is sort of hit or miss anyway whether this information is supported at all. So good enough for now. Issue #5 Change-Id: Ia0d09a0c4b92756f68c2a09a114311b363fef33a Reviewed-on: https://cue-review.googlesource.com/c/cue/+/9370 Reviewed-by: CUE cueckoo <cueckoo@gmail.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
This issue has been migrated to cue-lang/cue#5. For more details about CUE's migration to a new home, please see cue-lang/cue#1078. |
Tracking issue for adding protobuf support to CUE:
The text was updated successfully, but these errors were encountered: