Move tool dependencies to a separate module

[skitt]

This reduces the module dependency tree for third-party projects depending on mcs-api (or at least, mcs-api's influence on the module dependency tree).

[RainbowMango]

Reduce the dependencies for third-party project is great! /lgtm

We still need a way, like a hack/update-xxx.sh, to manage the modules, especially go.mod/go.sum, right?

[skitt]

Reduce the dependencies for third-party project is great! /lgtm

We still need a way, like a hack/update-xxx.sh, to manage the modules, especially go.mod/go.sum, right?

The project currently doesn’t have anything for the main module, so I didn’t add anything for the tools module — it can be managed with go -C tools mod … or inside the tools directory. The tricky part is that the Kubernetes code generator produces code that may require bumping the client-go dependency in the main module; for example, the 0.31 code generator produces code dependent on 0.31 client-go packages:

$ go -C tools get k8s.io/[email protected]
[…]
$ hack/update-codegen.sh
[…]
$ go mod tidy
go: finding module for package k8s.io/client-go/gentype
go: sigs.k8s.io/mcs-api/pkg/client/clientset/versioned/typed/apis/v1alpha1 imports
	k8s.io/client-go/gentype: module k8s.io/client-go@latest found (v0.30.2), but does not contain package k8s.io/client-go/gentype

So a script which upgrades k8s.io dependencies in lockstep would be useful.

[RainbowMango]

Interesting! I reproduced it on my side.

Just a guess, when tiding the main module, go command figures out that the current version of client-go(v0.30.0) is outdated as missing some package or functions, so it decides to bump it to the latest, that is the v0.30.2.

So a script which upgrades k8s.io dependencies in lockstep would be useful.

Yes, that's exactly what I'm talking about. We have to take care of all modules when bumping kubernetes dependencies.

[RainbowMango]

By the way, I'm not meaning that should be done in this PR. This PR looks good to me.

[skitt]

Interesting! I reproduced it on my side.

Just a guess, when tiding the main module, go command figures out that the current version of client-go(v0.30.0) is outdated as missing some package or functions, so it decides to bump it to the latest, that is the v0.30.2.

I can’t remember where this is documented, but essentially, go starts from the latest and works its way back until it finds a set of module versions which all work together (or bails out). In this instance, k8s.io/client-go/gentype was added in 0.31.0-alpha.3 (by me :wink:), which isn’t accessible by working back from latest. (Once 0.31 is released, this will “just work”.)

[RainbowMango]

Yeah, I see, that is https://github.com/kubernetes/kubernetes/pull/121439.

Go command would ignore pre release by default, but we can force it to take the pre release like this:

diff --git a/go.mod b/go.mod
index 18fcb74..0b8677a 100644
--- a/go.mod
+++ b/go.mod
@@ -10,7 +10,7 @@ require (
        github.com/onsi/gomega v1.33.0
        k8s.io/api v0.30.0
        k8s.io/apimachinery v0.30.0
-       k8s.io/client-go v0.30.0
+       k8s.io/client-go v0.31.0-alpha.3
        k8s.io/utils v0.0.0-20230726121419-3b25d923346b
        sigs.k8s.io/controller-runtime v0.18.2
        sigs.k8s.io/kind v0.23.0

[skitt]

… or go get k8s.io/[email protected]!

[skitt]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nojnhuh, skitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [skitt]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment