Paul Jolly

Thanks for the catch.

> First one is obvious: `gobin -m -run github.com/golangci/golangci-lint/cmd/golangci-lint` is a way harder to type than just `golangci-lint`. Agreed. The generally accepted solution for humans is to use aliases. For...

Please can you confirm the version of `gobin` you are using?

I'm minded to agree with your suggestion here. Indeed I'm somewhat surprised we didn't do this to start with. `gobin` needs a bit of a rewrite and so I'll bundle...

Thank you for raising this, and apologies again for being slow at responding. As you are aware, other demands on my time right now. There has been some significant discussion...

My immediate response would be "no" simply because we've all managed to live with the `go` command not being a library! It just feels like we'd be creating another API...

> Do we need one go.mod file per tool dependency? I would argue yes, and I suspect @rogpeppe would too. Various reasons: * brings versioned tool use within a project...

> Not convinced that this is a clear decision, but I see it's a tradeoff. Agreed. > ... which is already a non-trivial amount of clutter. Indeed.

There are two reasons why I think we should still have a `go.{mod,sum}` per main package module: * handles the case where the main package's module might not be tidy/complete...

> > handles the case where the main package's module might not be tidy/complete > > If we live in a world where `proxy.golang.org` is the standard for open source...