Open oxisto opened 6 months ago
It seems that https://github.com/open-policy-agent/opa/pull/5939 introduces this issue
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?
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.
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 therego
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
andtopdown
packages, but that is besides the point for now. (Interesting side-node..plugins
uses github.com/cespare/xxhash/v2 from prometheus andlast
uses github.com/OneOfOne/xxhash).As far as I can see the "culprit" is the
pluginMgr
field in theRego
struct, which pulls in theplugins
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 inDescribe a "Good Enough" solution
Maybe, the
plugins.Manager
could live somewhere else in another package, so thatplugins
is not pulled but only this (common) package betweenrego
andplugins
.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.