thedavemarshall
commented
1 month ago @anakrish thanks for the thoughtful feedback!
I understand #254 to want the Engine to provide a way to obtain entire policy file contents. I don't think the PR addresses that yet.
ah I think I misunderstood when I first read those requirements, my mistake!
- We could expose AST publicly via a cargo feature. That will allow it to be used and refined based on feedback.
yeah, I think AST exposure is a great candidate for a rust crate feature
- We could version the AST.
I like this idea! Or at least versioning the JSON output?
- Instead of ad-hoc functions should we just define a mapping of AST nodes to json? We could then serialize entire AST to json and make it available to the different bindings as well.
I think this is similar to how opa does it for their policy HTTP API, docs
I'd love your feedback since you have a concrete usecase.
I think exposing a JSON representation of the AST is a good solution. Tomorrow I'll take an in-depth look at https://github.com/microsoft/regorus/pull/266 , which at first glance seems a great fit for my use case!
Closing this PR in favor of https://github.com/microsoft/regorus/pull/266
This change is to expose more package data from the engine, potentially addressing https://github.com/microsoft/regorus/issues/254
@anakrish I know you've mentioned the ast and some of the internals are unstable and being iterated on, so I'd love you input here if this is a good approach, or if you're not ready to expose these things through the engine.
I had some trouble getting a method of
package name -> [rule_name1, rule_name2], so I'm curious if there's a good way to do that with the current abstractions, or if that's something I could potentially help out with.