open-policy-agent / opa

Open Policy Agent (OPA) is an open source, general-purpose policy engine.
https://www.openpolicyagent.org
Apache License 2.0
9.56k stars 1.33k forks source link

Limit (indirect) dependencies in the `rego` package (esp. prometheus) #6754

Open oxisto opened 4 months ago

oxisto commented 4 months ago

What is the underlying problem you're trying to solve?

Hi! We are currently using the Rego Go API (not the SDK) to execute Rego files. This works quite well also with the "storage" options. There is only one drawback to our current solution. It seems that using the rego package introduces quite a lot of indirect dependencies, that we do not really need or use. This is mainly prometheus (including 10 indirect dependencies on prometheus itself) and open telemetry trace. In total, just importing the rego package imports the following packages:

This seems to be in contrast to the comment made here, https://github.com/open-policy-agent/opa/issues/2348#issuecomment-621132496, which said that plugins should not depend on prometheus.

It pulls even more dependencies from the ast and topdown packages, but that is besides the point for now. (Interesting side-node.. plugins uses github.com/cespare/xxhash/v2 from prometheus and last uses github.com/OneOfOne/xxhash).

As far as I can see the "culprit" is the pluginMgr field in the Rego struct, which pulls in the plugins package, which in turn pulls in all of the above.

Describe the ideal solution

Probably, plugins should work without prometheus and/or open telemetry, but I am not too familiar with the plugin system.

Ideally, if we are not using plugins (or the plugin manager), the package plugins should not be pulled in

Describe a "Good Enough" solution

Maybe, the plugins.Manager could live somewhere else in another package, so that plugins is not pulled but only this (common) package between rego and plugins.

Another possibility is maybe to move the plugins functionality from the rego package to the SDK? It's full feature-set including prometheus and tracing mainly seems to be tied to a "higher-level" use-case in my opinion.

Additional Context

Not really, but I am open to help in implementing this, once a design decision has been reached.

oxisto commented 4 months ago

It seems that https://github.com/open-policy-agent/opa/pull/5939 introduces this issue

srenatus commented 4 months ago

Yeah stuff like that's creeps in unintentionally. Ideally, some liner would protect our intentions.

Now, we cannot really move plugin.Manager, I think, but there might be other solutions...? Similar to how we handled #6500, maybe?

stale[bot] commented 3 months ago

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.