-
Notifications
You must be signed in to change notification settings - Fork 16
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
standardised format of json rule output #569
Conversation
…to json_rule_format
…e-oxide into json_rule_format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The formatting is much better!
We might want to keep expressions as raw AST output (as we have now) instead of in the pretty form. This allows us to more closely monitor changes on the internal representation of expressions.
Alternatively, we could store both forms.
By AST output do you mean the one we have in the "human rule traces" files?
|
I think we should keep the AST form only (as opposed to both) human readable version is in the txt files anyway. |
That makes sense. I just thought you wanted both the last time we talked. I should have asked before proceeding with the pr. Should I uncomment the changes or just delete the branch? |
Sorry I don't think I was being clear. @niklasdewally was suggesting/asking whether we want two versions of the JSON files. I was responding to that, I agree with what he said about using raw AST output in the JSON files instead of pretty. We still want the JSON version you worked on here. To be concrete, I am suggesting we print the AST instead of a pretty printed version like the following:
|
O, I got confused and thought we wanted to fully remove the json rules now. I am glad we still need it. So to be clear, everything is fine, I just to remove pretty printing the value associated with the JSON keys? |
Yes: the changes to the layout of the file are good, but instead of printing the model in essence-like syntax, we want it to be like the output of |
Yes, in the above example instead of |
Is this fine? I tried to make the values for Also the order of the keys is not very logical but I used sort_json_object so it would be standardised. I could implement a custom sorting if needed. |
I tried the
|
…to json_rule_format
|
… 2025-01-08) PR #569 accidentally reverted this change, causing ACCEPT=true failures on my Mac and some CI failures.
Creating standardised json output of rules where every piece of information is a key value pair. At first I tried to use
sort_json_object
but it led to the keys being sorted not in a logical, consequential order. Separate functionsort_json_rules
was developed to sort the json objects to allow standardisation of the output.