Paul Jolly

Per @rogpeppe, we should probably follow whatever `go run` does here.

Just noting the detail here, but another potential line of attack on capturing tool dependencies separately from the main module is to use an internal submodule. For example, consider the...

### Arguments for applying `replace`/`exclude` directives: * ...

### Arguments against applying `replace`/`exclude` directives: * If the `main` package's module is used as a dependency of another module, then, all else being equal, the `replace`/`exclude` directives will not...

### Option space Here we summarise the option space we have with respect to applying (or otherwise) `replace`/`exclude` directives, in an approximate order from "do nothing" to "apply everything": *...

.

Just noting another point as an aide memoire (will update main points in a bit): in the case of a slow-responding maintainer, `replace` statements are useful for both `main` packages...

Per our offline discussion, linking the very relevant https://github.com/golang/go/issues/26904#issuecomment-411873481: > Ideally, I think the long-term solution will be to treat replacements as rewriting the import paths rather than the source...

Reminder: * copy all replacements from the `go.mod` of the module containing the `main` package to the temporary `go.mod` * install the `main` package with the temporary `go.mod` as the...

Look at https://github.com/goreleaser/godownloader as a potential solution.