chore: move tools in a module to reduce root module bloat
This moves the tools dependencies in a dedicated module to reduce the bloat of the root module.
This should also reduce the amount of failed check generated CI jobs in renovate PRs, by not sharing the deps between our library and the tools that we are using.
The mix of make files and go generate seems unnecessarily complex, we might want to move everything to make files if this turns out to be painful.
While I personally like the division in "prod" and "dev" dependencies, I also appreciate the simplicity of using go run ... in the generate comments, it removes a bunch of steps from the pipeline.
In addition, while these dependencies are in our go.mod, they wont end up in downstream users go.mod because go is smart enough to only add the dependencies that are actually imported in the code you use.
Yes, I agree that the simplicity of go run is nice.
Part of the reason why I did this is that we have those jobs failing, a bit too often, for me to tidy the files manually every time:
https://github.com/hetznercloud/hcloud-go/actions/runs/11889479028/job/33126124091?pr=550#step:4:28
We could simplify this by using a makefile, and skipping go generate all together, would that work for you?
At that point we could just let renovate run goModTidy and merge !530.
We could simplify this by using a makefile, and skipping go generate all together, would that work for you?
That would also work, personally not that much of a fan of Makefiles if it can also be done in a language-native way, but I would not block it.
Why do we need a Makefile instead of doing it like in https://github.com/hetznercloud/cli/pull/901 with go run -C ./tools?
I am stepping back from this PR, @phm07 will take a look at this to see if its worth it.
Go 1.24 will add a tool directive to go.mod to specify these external binaries: https://tip.golang.org/doc/go1.24#go-command
Go 1.24 will add a
tooldirective togo.modto specify these external binaries: https://tip.golang.org/doc/go1.24#go-command
Wouldn't we need to update the module to 1.24 then as well? Since the new directive goes into the go.mod
Probably, not sure how Go <1.24 would handle these directives and if Go 1.24 only accepts them if the go.mod specifies 1.24 as the min version.
This PR has been marked as stale because it has not had recent activity. The bot will close the PR if no further action occurs.
This PR has been marked as stale because it has not had recent activity. The bot will close the PR if no further action occurs.