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:

• github.com/beorn7/perks
• github.com/cespare/xxhash/v2
• github.com/prometheus/client_golang
• github.com/prometheus/client_model
• github.com/prometheus/common
• github.com/prometheus/procfs
• go.opentelemetry.io/otel
• go.opentelemetry.io/otel/metric
• go.opentelemetry.io/otel/sdk
• go.opentelemetry.io/otel/trace
• github.com/gorilla/mux

This seems to be in contrast to the comment made here, #2348 (comment), 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.