Need help?

[jondot]

Hi,
I've built a few infra projects bridging OPA to Rust.
This project looks like what I wanted to build -- any way I can help? (roadmap, issues list to pick up, etc.?)

[sandhose]

Hi! Thanks for reaching out :)

What would help me is for you to try it out! It's pretty much usable, we're using it in the matrix-authentication-service here: https://github.com/matrix-org/matrix-authentication-service/blob/482bfeecc2abc44f36d0a6fa696168cd7e6ef1a4/crates/policy/src/lib.rs
It's not published on crates.io yet, but you can use it as a git dependency like that: https://github.com/matrix-org/matrix-authentication-service/blob/482bfeecc2abc44f36d0a6fa696168cd7e6ef1a4/crates/policy/Cargo.toml#L10

The feedback I'm looking for is:

• is exposing the WASM engine (as in, you have to manage it yourself) the right abstraction?
• would you like to have a higher-level abstraction? If so, how should it look like?
• all the APIs are async, with a dependency on tokio. Is that a blocker for you? Would you need support for other runtimes and/or sync versions of all this?

You could also help by implementing builtins defined in this list: #1
You can look at existing builtin impls for inspiration

[jondot]

Hi! I've started working on the builtins, so far really nice experience, kudos!
I'm interested to hear what kind of test strategies were you thinking for this crate?

I've seen:

• Integration testing #2
• The usage in matrix-authentication-service

I've also:

• Got an example from the OPA playground
• Built it to wasm with opa build -t wasm -e example rule.rego and unpacked the bundle.tar.gz
• Ran the resulting policy with opa-eval --module ./policy.wasm --data-path ./input.json --entrypoint example
  And that worked nicely.

Before I start full-out implementing builtins, I'm looking for a productive way to test my work. I feel there's probably a really optimal way to test, more of a blackbox against the official OPA test suite, but what ever way -- that the test rig should probably be built in Rust inside this repo, or maybe there's a way to avoid that and test differently?

Happy to hear if you had thoughts or are already testing in a different way?

[jondot]

@sandhose I went ahead, couldn't wait. Check it out here: #4
Happy to hear your thoughts

[sandhose]

@jondot Thanks a lot for that! Sorry for not getting back to you earlier, I was out of office the past week ; I will review that this week.
What would help me is if you splitted the changes into two PRs, one for the integration tests and the other for the UUID builtin implementation.

[jondot]

No worries,
Just to highlight - in this case actually the UUID implementation is not important, so you can ignore the actual details of it (for example, I'm not seeding the generation, like I see in the Go impl) -- it's just a driver to "demo" the testing infra.
Either way I intend to re-do the UUID implementation.
Also, once I have an infra for testing which makes me feel comfortable coding at speed, I hope to go full bezerk mode implementing the builtins ;)

[jondot]

@sandhose hi 👋 trying to reach you here,
are you still accepting PRs to this project?

[sandhose]

@jondot Hi! I had this notification sitting in my inbox for way too long, and couldn't manage to find time to get back working on this project before. I'm very sorry about that.

I'm definitely still accepting PRs, and will try to streamline that process a bit more. I'll check with my employer if I can get other people reviewing PRs on this project, or if I can get you maintainers rights on the project, so that it's not completely dependant on me.

[jondot]

Hey @sandhose!, no worries, fantastic, we'll keep pushing more builtins, I believe we can cover everything soon (most of the challenging parts are done).