你正在使用哪个版本的Go( go version
)?
$ go version
go version devel +4b3f04c63b Thu Jan 10 18:15:48 2019 +0000 linux/amd64
这个问题在最新版本中是否会重现?
是的
你正在使用什么操作系统和处理器架构( go env
)?
go env
输出
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rog/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/rog/src/go"
GOPROXY="http://localhost:3000"
GORACE=""
GOROOT="/home/rog/go"
GOTMPDIR=""
GOTOOLDIR="/home/rog/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/m/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build480679307=/tmp/go-build -gno-record-gcc-switches"
你做了什么?
这里有一个脚本,它说明了这个问题(通过将内容保存到文件并在上面运行测试脚本命令来重现问题( go get github.com/rogpeppe/go-internal/cmd/testscript
))
# Create the module and tidy it.
go mod init m
go mod tidy
cmp go.mod go.mod-after-tidy
# Run a `go list` command to list the parent of the used package.
go list github.com/btcsuite/btcutil
cmp go.mod go.mod-after-list
# Running `go mod tidy` removes the new dependencies.
go mod tidy
cmp go.mod go.mod-after-tidy
-- main.go --
package main
import _ "github.com/btcsuite/btcutil/base58"
func main() {
}
-- go.mod-after-tidy --
module m
go 1.12
require github.com/btcsuite/btcutil v0.0.0-20180706230648-ab6388e0c60a
-- go.mod-after-list --
module m
go 1.12
require (
github.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d // indirect
github.com/btcsuite/btcutil v0.0.0-20180706230648-ab6388e0c60a
golang.org/x/crypto v0.0.0-20181203042331-505ab145d0a9 // indirect
)
我不希望 go list
向 go.mod
添加实际上未被代码使用的依赖项。
6条答案
按热度按时间ndasle7k1#
相关 #29452 。我认为在更改之前,我们需要就
go list
应该具有的副作用做出决定。我相信这目前正按照设计工作。
cmd/go
将信息保存到go.mod
中,以便命令可重复执行(包括go list
)。然而,这并非许多人对go list
的期望。dpiehjr42#
@jayconrod,这个问题是否相同?请注意,由于
go mod tidy
已经运行,@rogpeppe已经有了这个问题的模块作为要求。事实上,重新运行tidy会再次删除额外的间接行。我认为这不仅仅是一个“列表不应该有副作用”的问题。inb24sb23#
我认为这是同样的问题。主模块依赖于包
github.com/btcsuite/btcutil/base58
,它在标准库之外没有任何依赖项。go list github.com/btcsuite/btcutil
添加了该包的传递依赖项。go mod tidy
移除了这些依赖项,因为主模块中没有模块传递地依赖于它们。go mod tidy
实际上像一个垃圾回收器:它移除了对无法从主模块中的包到达的模块的要求。2vuwiymt4#
#29452 与 #26977 相关但不同。
#26977 可能存在相同的底层问题。可以认为,
go mod why
和go list
(不包括-versions
)都应该避免解析请求的软件包,除非它已经在构建列表中的某个模块中。oiopk7p55#
嗯,这与#26977的情况并不完全相同:在这种情况下,有问题的包已经位于一个活动模块中,但该模块的依赖项尚未解析。
go list
作为加载包的副作用来解析这些依赖项,但由于您实际上没有请求有关包导入的任何信息,我们可以认为不需要加载它们。(另请参阅#29666。)tquggr8v6#
经过进一步考虑,我认为这与 #29666 大体上是重复的。相反,如果你要求关于 依赖关系 的
github.com/btcsuite/btcutil
的任何实质性信息(例如,通过使用-f '{{.ImportMap}}'
或-json
检查ImportMap
字段),那么go
工具应该可以说将相应的版本信息添加到go.mod
文件中,以确保命令的输出可重现。