This proposal is to replace the current use of go build with go install in our build process. The primary goal is to simplify and reduce the burden of managing dependencies, particularly in relation to the hack/tools/go.mod file.
Motivation
Currently, maintaining hack/tools/go.mod consumes a significant amount of time due to the need to ensure compatibility among different versions of packages used by all tools installed into hack/tools/bin. The resolution of conflicting libraries between tools such as kind, clusterclt, and kubectl is often time-consuming. It brings into question the necessity of such a labor-intensive approach.
The present method, utilizing tools.go, has led to the "diamond dependency problem". For instance, through tools.go, we may depend on two separate packages - let's call them packageOne and packageTwo. Both of these packages depend on a third package, packageCommon. The problem arises when packageOne requires a different version of packageCommon than packageTwo, resulting in a conflict.
Detailed Explanation
go install is a viable solution to simplify this process and reduce the occurrence of the "diamond dependency problem". It fetches and installs the packages named in the import paths along with their dependencies. This process uses the existing compiled package binary if available instead of building the source code from scratch, which provides a potential performance improvement.
Using go install instead of go build will make dependency management more straightforward and potentially reduce the time spent on resolving conflicting libraries.
Potential Drawbacks
I currently do not have an easy solution for the transition from go build to go install. A detailed plan and more in-depth discussion is required. This change may also affect the build process in ways that we can't foresee without further testing.
Conclusion
In conclusion, I propose we replace go build with go install to mitigate the "diamond dependency problem" and reduce the time spent on maintaining the hack/tools/go.mod. While a detailed transition plan is yet to be created, the potential benefits warrant serious consideration of this change.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
/kind feature
Describe the solution you'd like
Summary
This proposal is to replace the current use of
go buildwithgo installin our build process. The primary goal is to simplify and reduce the burden of managing dependencies, particularly in relation to thehack/tools/go.modfile.Motivation
Currently, maintaining
hack/tools/go.modconsumes a significant amount of time due to the need to ensure compatibility among different versions of packages used by all tools installed intohack/tools/bin. The resolution of conflicting libraries between tools such askind,clusterclt, andkubectlis often time-consuming. It brings into question the necessity of such a labor-intensive approach.The present method, utilizing
tools.go, has led to the "diamond dependency problem". For instance, through tools.go, we may depend on two separate packages - let's call thempackageOneandpackageTwo. Both of these packages depend on a third package,packageCommon. The problem arises whenpackageOnerequires a different version of packageCommon thanpackageTwo, resulting in a conflict.Detailed Explanation
go installis a viable solution to simplify this process and reduce the occurrence of the "diamond dependency problem". It fetches and installs the packages named in the import paths along with their dependencies. This process uses the existing compiled package binary if available instead of building the source code from scratch, which provides a potential performance improvement.Using
go installinstead ofgo buildwill make dependency management more straightforward and potentially reduce the time spent on resolving conflicting libraries.Potential Drawbacks
I currently do not have an easy solution for the transition from
go buildtogo install. A detailed plan and more in-depth discussion is required. This change may also affect the build process in ways that we can't foresee without further testing.Conclusion
In conclusion, I propose we replace
go buildwithgo installto mitigate the "diamond dependency problem" and reduce the time spent on maintaining the hack/tools/go.mod. While a detailed transition plan is yet to be created, the potential benefits warrant serious consideration of this change.Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
kubectl version)/etc/os-release):