Well, I am sure that using one go.mod is not the best practice for not downloading unnecessary dependencies. For example, users who use apiserversdk as a library may not need to download grpc gateway at all. However, using one go.mod indeed simplifies many things.

Well, I am sure that using one go.mod is not the best practice for not downloading unnecessary dependencies. For example, users who use apiserversdk as a library may not need to download grpc gateway at all. However, using one go.mod indeed simplifies many things.

Yeah you are right from this point of view. Let me update the PR description a bit to be more clear. What I meant not the best practice is "Having multiple go.mod files and using replace in each of them". If in the future, kuberay become a large size package. We can then switch back to multiple go.mod but with go workspace. But at this point, using one go.mod should be easiest.

LGTM. Only have 2 questions:

• Did you run go mod tidy?
• Are there version conflicts and how did you resolve them?

1. Yes I ran go mod tidy
2. I didn't run into any version conflicts. I guess it's because we have been quite active on upgrading packages.

Having multiple go.mod files and using replace in each of them is hard to manage and not the best practice.

Not sure I would consider having multiple modules as not a best practice. I think it depends.

Just FYI that this change is potentially breaking Go compatibility for any external project that is importing github.com/ray-project/kuberay/ray-operator. Were we aware of this when making this change?

The benefit of the module in github.com/ray-project/kuberay/ray-operator was that it had a minimal amount of dependencies for importing CRD types and controller utils. With a single Go module, other repos now need to take in all dependencies of KubeRay even if they only need ones for ray-operator

Reviewing go modules in v1.3, I tend to agree we had way too many go modules, but I would suggest keeping the one in ray-operator because many users are importing the CRD types into their own projects and this change will now require those projects to inherit more dependencies

The benefit of the module in github.com/ray-project/kuberay/ray-operator was that it had a minimal amount of dependencies for importing CRD types and controller utils.

We have taken this into consideration. You can take a look at: #3640 (comment).

We decided to unify go.mod because we were spending too much time resolving dependency issues.