Skip to content
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

Add an option to relax semantic equivalence requirement on compile package #5035

Closed
tsandall opened this issue Aug 22, 2022 · 0 comments · Fixed by #5038
Closed

Add an option to relax semantic equivalence requirement on compile package #5035

tsandall opened this issue Aug 22, 2022 · 0 comments · Fixed by #5038

Comments

@tsandall
Copy link
Member

tsandall commented Aug 22, 2022

Currently the opa/compile package and the opa build command (which is implemented on top of the compile package) guarantees that emitted bundles are semantically equivalent to the input .rego files provided by the caller. This means that any query that could be run against the provided .rego files can also be run against the emitted bundle. This is nice in cases where the bundle is to be fed back into OPA, because callers of OPA can be unaware of any optimizations to the bundle.

On the other hand, in some cases, it's not possible to produce a semantically equivalent bundle because of limitations like the one discussed in #4411. For example:

package x

p[1]

f(x) { p[x] }

Will fail to build w/ entrypoint x/p because the function f refers to the entrypoint (0402892d8ee5a223453ee41cf4bfad446f11aea2):

opa build -t wasm -e x/p foo.rego

In many compiler use cases, the consumer may not require semantically equivalent bundles. In those cases, we should relax the requirement on the compile package. A simple option like --prune-unused on opa build and a similar option on the compile package would be enough.

srenatus added a commit to srenatus/opa that referenced this issue Aug 23, 2022
With `.WithPruneUnused(true)`, the compiler (of the compile package) no longer
collects dependents of its entrypoints.

The resulting bundle, if used with the wasm target, will no longer be
semantically equivalent to the bundle built with the rego target.

Since we're unable to have entrypoints for functions, this allows building
modules that we couldn't build before. See open-policy-agent#5035.

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
srenatus added a commit that referenced this issue Aug 23, 2022
* compile: allow opt-out of dependents gathering

With `.WithPruneUnused(true)`, the compiler (of the compile package) no longer
collects dependents of its entrypoints.

The resulting bundle, if used with the wasm target, will no longer be
semantically equivalent to the bundle built with the rego target.

Since we're unable to have entrypoints for functions, this allows building
modules that we couldn't build before.

Fixes #5035.

* cmd/build: expose new configurable via --prune-unused

Signed-off-by: Stephan Renatus <stephan.renatus@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant