cmd/go: add option to run "go mod tidy" recursively on nested modules

[echarrod]

What version of Go are you using (go version)?

$ go version 1.13.12 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\harroded\AppData\Local\go-build
set GOENV=C:\Users\harroded\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\harroded\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\harroded\repos\yoti-go-sdk\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\harroded\AppData\Local\Temp\go-build068344166=/tmp/go-build -gno-record-gcc-switches

What did you do?

go mod tidy ./...
With a file structure like:

• mypackage
  • go.mod
  • _examples
    • one
      • go.mod
    • two
      • go.mod
    • three
      • go.mod

What did you expect to see?

Recursively run go mod tidy on subfolders

What did you see instead?

go mod tidy: no arguments allowed

Although having multiple modules inside doesn't seem to be always wise for everyone, and I know some people are against it, taking the advice from https://github.com/golang/go/wiki/Modules#should-i-have-multiple-modules-in-a-single-repository, there are still cases where it is useful, and it would be good to support this option

[bcmills]

The ... wildcard in arguments to the go command is a package pattern, not a directory pattern. That package pattern matches only packages in the main module — so go mod tidy ./... would mean the same thing as go mod tidy.

And this is pretty easy to do as a bash command or script if you so desire:

for f in $(find . -name go.mod)
do (cd $(dirname $f); go mod tidy)
done

[bcmills]

CC @jayconrod @matloob, but I don't think this carries its weight in the go command — especially given how rarely nested modules should be used in the first place.

[jayconrod]

I don't think we should support this. Go commands generally operate in the context of a specific "main" module. Running go mod tidy across multiple main modules would be very different from anything done today.

[echarrod]

I understand it's quite rare. We took this approach after seeing it done in https://github.com/cucumber/godog, as the use case of having multiple modules seems to suit our needs, I seem to remember seeing it in other places too, although can't remember where right now

EDIT: more examples

• https://github.com/FluuxIO/go-xmpp/tree/master/_examples
• https://github.com/elastic/go-elasticsearch/tree/master/_examples/fasthttp

[mvdan]

And this is pretty easy to do as a bash command or script if you so desire:

I agree with Bryan. I've been doing something similar, with a bit more care about ignoring huge directories:

go-modules() {
        find . \( -name vendor -o -name '[._].*' -o -name node_modules \) -prune -o -name go.mod -print | sed 's:/go.mod$::'
}

Then, I can just do something like: for m in $(go-modules); do (cd $m && go mod tidy); done

[mitar]

I also found this issue because I was searching on how to manage dependencies used only in _examples. I think instead of supporting recursive go.mod it would be better that go.mod could have separate sections of dependencies for the the library, main programs, examples, and tests. Now everything is cramped in there in the same place.

[mvdan]

@mitar that overlaps with existing issues like #26955. If you also think examples should be treated differently, please open a new issue instead.

[mitar]

For now I just made a dummy _ "dependency" import in a test file, so #26955 should probably cover that as well.

[seankhliao]

I think this will naturally be solved with #50745