-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
Projects building on top of OPA or integrating OPA via options like Wasm, plan evaluation, whatnot, often support only a subset of OPA's features and built-in functions. This is sometimes intentional (e.g. to disable http.send) and other times simply a matter of not yet having implemented some specific feature/builtin. While OPA's capabilities feature allows making its compiler aware of these restrictions for commands like opa build, opa check or opa test, the current approach of users pointing out desired capabilities via an extra --capabilities flag itself comes with some drawbacks:
- User must first create or obtain a
capabilities.jsonfile based on their requirements - User must remember to always provide the
--capabilitiesfile to all capabilitiess-aware commands - A project's capability requirements are all defined out-of-band — like in docs, not in the project's code
Allowing a project to point to their "capabilities" inside a bundle directory's .manifest file would address point 2-3. Also allowing the capabilities reference to point to a remote URL would at least for some cases also simplify point 1, as it would be much easier to reference capabilities.json files published by different projects.
Commands that allow both the --bundle and --capabilities arguments (like mentioned above) would no longer have to explicitly provide --capabilities if this is provided in the manifest. The command line arg should however still have higher precedence to allow quick overrides.
This originally came up in swift-opa, but would be of benefit for many projects integrating OPA in one way or another.