你正在使用哪个版本的Go( go version
)?
$ go version 1.13.12 windows/amd64
这个问题在最新版本中是否会重现?
是的
你正在使用什么操作系统和处理器架构( go env
)?
go env
输出
$ 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
你做了什么?
go mod tidy ./...
我使用了如下的文件结构:
- mypackage
- go.mod
- _examples
- one
- go.mod
- two
- go.mod
- three
- go.mod
你期望看到什么?
递归地运行 go mod tidy
在子文件夹上
你实际上看到了什么?
go mod tidy: no arguments allowed
尽管对于每个人来说,在多个模块中似乎并不总是明智的,我知道有些人反对它,但是根据 https://github.com/golang/go/wiki/Modules#should-i-have-multiple-modules-in-a-single-repository 的建议,仍然有一些情况下它是有用的,支持这个选项将会很好。
8条答案
按热度按时间i2loujxw1#
在
go
命令的参数中的...
通配符是一个包模式,而不是目录模式。这个包模式只匹配主模块中的包——所以go mod tidy ./...
和go mod tidy
的意思是相同的。如果你愿意的话,这作为
bash
命令或脚本是非常容易做到的:qltillow2#
CC @jayconrod@matloob,但我认为这在
go
命令中并不具有重要性——尤其是考虑到嵌套模块本来就应该很少使用。kx1ctssn3#
我认为我们不应该支持这个。Go命令通常在特定的"主"模块的上下文中运行。在多个主模块之间运行
go mod tidy
与今天所做的任何事情都有很大的不同。bwleehnv4#
我理解这相当罕见。我们在看到 https://github.com/cucumber/godog 中这样做之后采用了这种方法,因为具有多个模块的使用案例似乎适合我们的需要,我似乎还记得在其他地方也见过它,尽管现在想不起来是哪里了
编辑:更多例子
https://github.com/FluuxIO/go-xmpp/tree/master/_examples
https://github.com/elastic/go-elasticsearch/tree/master/_examples/fasthttp
ifsvaxew5#
这很容易做到,如果你愿意的话,可以使用
bash
命令或脚本:我同意Bryan的观点。我一直在做类似的事情,只是更小心地忽略了巨大的目录:
然后,我可以像这样操作:
for m in $(go-modules); do (cd $m && go mod tidy); done
jaql4c8m6#
我也发现了这个问题,因为我在搜索如何管理仅在
_examples
中使用的依赖项。我认为,与其支持递归的go.mod
,不如让go.mod
能够为库、主程序、示例和测试分别有独立的依赖项部分。现在所有东西都挤在同一个地方。2vuwiymt7#
@mitar,这与现有的问题#26955重叠。如果您还认为示例应该有所不同,请打开一个新的问题。
oxf4rvwz8#
目前,我在测试文件中创建了一个虚拟的
_ "dependency"
导入,因此 #26955 也应该涵盖这一点。