`cmd/go: 'go list' 不应解析或记录与请求的输出字段无关的模块,

nbysray5  于 2个月前  发布在  Go
关注(0)|答案(6)|浏览(33)

你正在使用哪个版本的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 listgo.mod 添加实际上未被代码使用的依赖项。

ndasle7k

ndasle7k1#

相关 #29452 。我认为在更改之前,我们需要就 go list 应该具有的副作用做出决定。
我相信这目前正按照设计工作。cmd/go 将信息保存到 go.mod 中,以便命令可重复执行(包括 go list )。然而,这并非许多人对 go list 的期望。

dpiehjr4

dpiehjr42#

@jayconrod,这个问题是否相同?请注意,由于go mod tidy已经运行,@rogpeppe已经有了这个问题的模块作为要求。事实上,重新运行tidy会再次删除额外的间接行。我认为这不仅仅是一个“列表不应该有副作用”的问题。

inb24sb2

inb24sb23#

我认为这是同样的问题。主模块依赖于包 github.com/btcsuite/btcutil/base58,它在标准库之外没有任何依赖项。go list github.com/btcsuite/btcutil 添加了该包的传递依赖项。go mod tidy 移除了这些依赖项,因为主模块中没有模块传递地依赖于它们。
go mod tidy 实际上像一个垃圾回收器:它移除了对无法从主模块中的包到达的模块的要求。

2vuwiymt

2vuwiymt4#

#29452#26977 相关但不同。
#26977 可能存在相同的底层问题。可以认为,go mod whygo list(不包括 -versions)都应该避免解析请求的软件包,除非它已经在构建列表中的某个模块中。

oiopk7p5

oiopk7p55#

嗯,这与#26977的情况并不完全相同:在这种情况下,有问题的包已经位于一个活动模块中,但该模块的依赖项尚未解析。
go list作为加载包的副作用来解析这些依赖项,但由于您实际上没有请求有关包导入的任何信息,我们可以认为不需要加载它们。(另请参阅#29666。)

tquggr8v

tquggr8v6#

经过进一步考虑,我认为这与 #29666 大体上是重复的。相反,如果你要求关于 依赖关系github.com/btcsuite/btcutil 的任何实质性信息(例如,通过使用 -f '{{.ImportMap}}'-json 检查 ImportMap 字段),那么 go 工具应该可以说将相应的版本信息添加到 go.mod 文件中,以确保命令的输出可重现。

相关问题