-
Notifications
You must be signed in to change notification settings - Fork 5
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
Implement Python support for writing rules #98
Comments
I am only now realizing policy plugins don't work the way I had thought. Instead of having a plugin per policy pack, we have a single universal plugin, This seems like it will fundamentally make it difficult to ever support more than just Node.js. The alternative, which I assumed we were doing, was to use the plugin system to distribute, install, and manage policy packs, and to use the ability to have many versions side-by-side. That would get us multi-language while also aligning with how the rest of the system works. And yet that's a fairly fundamental change. @justinvp Have you thought much about this? Do you have an alternative in mind that is simpler to get to from where we are? I hit this because I need to write a policy pack in Go. |
The current policy plugin system assumes that the target plugin uses our opinionated Node.js loader shim to set up the plugin. This makes it impossible to leverage plugins written in other languages (like [Python](pulumi/pulumi-policy#98) or, in my case, Go). It turns out this shim isn't entirely required. It's actually just there for convenience, as it hides the boilerplate of implementing the gRPC analyzer server necessary to communicate with the engine. If you've implemented said interface by hand, or via some alternative mechanism, there's no reason we can't just load the plugin like we do with other plugins -- languages, resource providers, etc. This change is arguably a bit of a hack. It looks at the target --policy-pack and, if it's a directory, keeps the old behavior of using the Node.js shim. If it's a file, on the other hand, it assumes that file is the plugin binary and loads it directly. I'm not actually suggesting this is the right way to do it. But it does unblock the project I'm currently tinkering with. This also calls into question what approach we'd actually want to take with service-managed policy packs. Either way, we will need to figure out what approach to take that supports authoring policy packs in different languages.
I'm going to close this meta-issue since we have smaller issues tracking the reamining work to do here (linked in the description). |
Meta issue tracking the following work:
The text was updated successfully, but these errors were encountered: