-
Notifications
You must be signed in to change notification settings - Fork 274
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
encoding/cuedata: Add CUEdata package #1434
base: master
Are you sure you want to change the base?
Conversation
5c49774
to
56e1747
Compare
@codewithcheese thank you for raising this PR, we're delighted to welcome new contributions! Referring to the contribution guide, please can I check where this particular approach/design has been previously agreed? I can quite understand that you might have wanted to jump in and have a get familiar with the code. At the same time, we want to be respectful of people's time, and discuss changes ahead of time:
|
hey @myitcv, I opened this discussion #1250 but unfortunately it was during the summer holidays and it did not receive much attention at the time. I recently discovered #130, and realized in retrospect, that I should have likewise utilized an issue to explore how to solve the use case we were facing. |
This is a very fair point. Thank you for being patient! We absolutely don't want to discourage contributions by referring people to the contributing guide. Instead we want to be as sensitive and respectful of people's time, as I mentioned above. So my suggestion would be as follows: let's either reuse #130, convert #1250 to an issue, or create a new issue (as you see fit) to discuss in more detail what you're proposing, the use case motivating it, how existing mechanisms fall short etc. The reason I stress an issue here is that our workflow for proposals is issue-based, not discussions. That might seem like a small thing, but with lots of issues/discussions, we need some process. If we go quiet, please feel free to ping us with Thank you again for your contribution, but above all else your patience and understanding during the summer months. I will help to move along whatever issue discussion so we get a quick decision on next steps. |
Signed-off-by: Thomas Manning <thomasm@balena.io>
56e1747
to
9dd6fab
Compare
Introduces a new (en|de)coder to covert any CUE file to and from a literal data format. Non concrete expressions in each struct are serialized into a syntax string and added as a field, labelled
$$cue
.This allows for CUE files to be stored and transmitted as structured data. Our use case at balena is to store CUE files in a document database and query against the concrete values, the resulting documents can then be decoded back to CUE and evaluated as CUE. I think others would share a similar use case, hence I am creating this PR. If this is not acceptable, we will create it as a standalone tool.
I have named the format
CUEdata
, but I am open to alternatives. I see in issue #130QSON
as in "Q (CUE) Strict Object Notation" andCUEL
as in "CUE Literal" were suggested.This address #1250, for our needs its a more complete solution than JSONSchema, since it allows the document to contain arbitrarily complex CUE expressions that could not be encoded as JSONSchema.
I am new to the Go language and this is an implementation by imitation, I have probably copied some techniques that the CUE code base would like to move away from. I am not aware of all the Go idioms. Please feel free to let me know any better solutions.
Resolves #1435