Remove CI dependencies from go.mod

[kszafran]

We still pin library versions, but without polluting go.mod (which also pollutes go.mod files of projects that depend on this library).

[F21]

Hey @kszafran, thanks for this PR.
Unfortunately, what this does is scatter the pinning of the versions for those tools across many files, opening the possibility for someone to forget to update a version in one of the files and thus introducing an inconsistency. In addition, it also stops us from using the standard go tools such as go get to update those dependencies and prevents developers who are not using docker to install and run the correct version of golangci-lint etc.

I agree that the transitive dependencies are annoying, but as Go currently lacks the concept of development dependencies, the tools.go method is currently the best and commonly used approach to deal with this problem.

[kszafran]

Thank you for the response. I was actually not aware that having something like tools.go is a common practice. In our repositories we keep versions in .pre-commit-config.yaml, which works fine for linters. I looked briefly through this thread. I haven't found there any consensus on what is the current best practice, but I found some ideas at least:

• separate go.tools.mod file: cmd/go: clarify best practice for tool dependencies golang/go#25922 (comment)
• a tool dedicated to solving this problem: https://github.com/bwplotka/bingo
• an example setup using a separate module: https://github.com/nordicdyno/golang-tools#motivation
• since 1.17 Go supports running with a version go run example.com/[email protected], which could be used in the Makefile (this seems to me to be the best approach, with the main downside being that golangci-lint version would be duplicated - in the Makefile and docker-compose.yml)

I'm just throwing some ideas out there, but it's of course up to you if you prefer to stay with the current approach.

[F21]

Thanks for looking in to this. With the current state of Go, I still think using tools.go is most idiomatic and easiest to manage. I'll go ahead and close this PR, but hopefully Go will offer a better solution for this use-case in the future.

Even though the transitive dependency is downloaded, it should not be compiled into your final binary if your code does not use any of it.