What would you like to be added?

I'm doing the prep work for kubernetes-sigs/kustomize#4401 which aims to import Helm as a Go library in kustomize instead of using the helm binary. I found that any package that depends on pkg/cli creates an import cycle. I realized this is because pkg/cli/environment.go imports pkg/kube, which pulls in fluxcd/cli-utils, then k8s.io/cli-runtime, then sigs.k8s.io/kustomize/api creating a cycle back to our own module.

I'd suggest decoupling pkg/cli.EnvSettings from pkg/kube. Currently environment.go imports pkg/kube (for the RESTClientGetter in Namespace() and GetConfig()), which makes it impossible for kustomize to use any Helm package that depends on pkg/cli, since cli-runtime already imports kustomize/api.

If possible, maybe split EnvSettings into a pure-config struct (paths, namespace, debug flags, no kube imports) in a separate lightweight package, and keep the Kubernetes client setup in pkg/cli or pkg/kube. I also found the TODO: refactor this out of pkg/action comment on Pull.Settings which kinda suggests this direction was already considered? Not sure.

Why is this needed?

PR #13617 enabled using Helm as a Go library. But kustomize sits on both sides of the cli-runtime dependency graph, it's imported BY cli-runtime and now it wants to import Helm. This creates an import cycle for any Helm package that touches pkg/cli.

Currently this limits kustomize to pkg/engine, pkg/chart/*, and pkg/registry. The pkg/action, pkg/downloader, pkg/getter, and pkg/repo packages are all unreachable due to the cycle through pkg/cli -> pkg/kube -> cli-runtime -> kustomize/api.