go list
提供了一个 .Deps
,它具有 .Imports
的递归依赖关系列表。这很重要,因为它提供了运行 go build
所需的完整依赖关系列表。
不幸的是,没有为 TestImports
或 XTestImports
提供递归依赖关系。它们具有需要满足才能运行 go test
的依赖关系树,但检索该依赖关系列表并不容易(尤其是在尝试过滤掉 stdlib 条目时)。
目前
// Dependency information
Imports []string // import paths used by this package
Deps []string // all (recursively) imported dependencies
TestImports []string // imports from TestGoFiles
XTestImports []string // imports from XTestGoFiles
预期结果
// Dependency information
Imports []string // import paths used by this package
Deps []string // all (recursively) imported dependencies
TestImports []string // imports from TestGoFiles
TestDeps []string // all (recursively) imported dependencies from TestGoFiles
XTestImports []string // imports from XTestGoFiles
XTestDeps []string // all (recursively) imported dependencies from XTestGoFiles
这将允许类似以下命令输出运行 go build
或 go test
所需的完整依赖关系集。
go list -f '{{join .Deps "\n"}}{{if len .TestDeps}}{{"\n"}}{{end}}{{join .TestDeps "\n"}}{{if len .XTestDeps}}{{"\n"}}{{end}}{{join .XTestDeps "\n"}}' | sort | uniq
目前,您必须对 go list '{{join .Deps "\n"}}' $import_path
中的每个导入路径运行 .TestImports
和 .XTestImports
。
8条答案
按热度按时间3ks5zfa01#
如何使用单个
.TestDeps
来持有.Deps
以及所有传递性测试依赖项?这将与get
命令保持一致。例如,.Deps
与go get
中使用的相同,而.TestDeps
将与go get -t
中使用的相同。pftdvrlh2#
@mvdan,这看起来合理,并且同样适用于我的使用场景。
vlju58qv3#
如果其他人同意这个设计,我很乐意尝试一下。
iugsix8n4#
我也在想,如果我们要镜像
go get -t
,可能需要一个更好的名字。TestDeps
似乎意味着“仅测试依赖项”,而不是“包括测试依赖项的所有依赖项”。或许可以用
DepsWithTest
或DepsInclTest
。或者我们应该让TestDeps
仅成为传递的测试依赖项,用户需要根据需要使用Deps
和TestDeps
(或者以某种方式合并这两个列表)。bsxbgnwa5#
讨论的更改对Debian也同样有价值,我们目前查询的是
{{ .Deps }}
,完全错过了仅用于测试的依赖项。编辑:有人指出,在特定的使用场景(生成Built-Using字段)中,排除测试依赖项实际上是正确的,所以不用担心 :)。
lndjwyie6#
我将此作为一个提案,希望在Go 1.11树开放时做出决定。提议的更改也不是微不足道的,所以有提案是有道理的。
ff29svar7#
感谢@mvdan。如果与我使用相关的上下文有任何帮助,请告诉我。
kgqe7b3p8#
我们需要更一般地解决这个问题,为新的go/loader包。我认为这可以等到那之后再做——它可能会自然而然地出现。