See #866

from pprof.

Questions for pohly:

1. Can you articulate the concrete issues that would arise for Kubernetes from keeping chromedp (and others) as test-only dependencies?
2. How does K8 dependency checking work: is it Go package level, or Go module level. (If it is based on looking at go.mod and go.sum files, it is module level).

Details

We get much better testing using chromedp, so that will be hard to remove. The good thing is that it is a test-only thing, but so should not affect any user of Kubernetes at runtime.

Moving to a separate package may not suffice: go.mod and go.sum are per-module so the dependencies will still stick around even if things are in a separate package but in the same Go module? Though that depends on how K8 is controlling dependencies. If the K8 dependency checking is at the package level, moving to a separate package may suffice. If the K8 checking is actually looking at go.mod and go.sum files, moving to a separate package won't help.

An alternative that may work is to create a separate Go module inside the Git repository and move the chromedp based tests to that module. This will require at least some trade-offs:

1. Github actions will need to be updated to build and test multiple modules.
2. User workflows like go test ./... will have to change to also test other modules.

from pprof.

Can you articulate the concrete issues that would arise for Kubernetes from keeping chromedp (and others) as test-only dependencies?

Kubernetes doesn't really distinguish between code and test dependencies. If a dependency of Kubernetes depends on github.com/mailru/easyjson that's a problem because it becomes a dependency of the Kubernetes code base as a whole. The practical implications are lower, but it's still a dependency and needs case-by-case analysis instead of being able to not accept it as dependency at all.

chromedp currently doesn't raise any red flags. I suppose it just makes some of the Go tooling slower because it needs to check out more code when doing dependency checks and updates.

How does K8 dependency checking work: is it Go package level, or Go module level.

I suspect it depends and I am not an expert in that area. If you want to know the gory details, the tool which flagged the problem is https://github.com/kubernetes/kubernetes/tree/master/cmd/dependencyverifier.

Moving to a separate package may not suffice

Right, I meant module.

from pprof.

The Kubernetes folks are not happy:

Direct Dependencies: 187 
-Transitive Dependencies: 328 
-Total Dependencies: 368 
+Transitive Dependencies: 334 
+Total Dependencies: 374 
 Max Depth Of Dependencies: 19 
 All dependencies:

from pprof.