我正在使用go模块作为依赖项管理,并且在安装这样的东西时遇到了问题:
go get -u github.com/go-critic/go-critic/...
Run Code Online (Sandbox Code Playgroud)
上面的结果是:
go: cannot find main module; see 'go help modules'
Run Code Online (Sandbox Code Playgroud)
编辑: 这里的原始答案专门涉及Go 1.11中工具的状态。从Go 1.12发布以来,这不再是准确的。有关在Go 1.12及更高版本中处理此情况的详细信息,请参见此答案及其链接到的答案。
如果GO111MODULEvar设置为var ,即使on使用的go get是工具而不是新的依赖项,也必须在初始化的go模块目录树中才能使用。这是一个众所周知且争议很大的问题:
https://github.com/golang/go/issues/27643
https://github.com/golang/go/issues/24250
https://github.com/golang/go/issues/25922
短期解决方案是运行GO111MODULE=off go get <tool>。即使您当前在模块包中,这也会显式禁用模块支持,并强制其仅使用您的GOPATH。
长期来看,找出最好的解决方案是通过go get(或go install带有标志的其他命令)支持工具安装,这是一个正在进行的讨论领域,到目前为止,建立共识的方式还很少。但是,Go 1.12 有一个PR开放,如果被接受,它将允许go get在模块外部甚至在GO111MODULE=on设置的情况下简单地工作。
此时,这里的其他几个答案已经过时了。
至少要考虑两种情况:
您想要安装工具,但不想修改当前版本go.mod以将其作为依赖项进行跟踪。
简而言之,对于Go 1.12或1.13,最简单的解决方案是访问cd不带的目录go.mod,例如:
$ cd /tmp
$ go get github.com/some/tool@v1.0.1
Run Code Online (Sandbox Code Playgroud)
另外,gobin是安装或运行二进制文件的模块感知命令,它提供了额外的灵活性,包括无需更改当前模块的安装即可安装的能力。go.mod
有关更多详细信息,请参见此相关答案,包括Go 1.11的解决方案,以及Go 1.14中可能的新选项,以获取无需更新您的工具的工具go.mod。
另一方面,如果要在中将工具作为版本依赖性明确地跟踪go.mod,请参阅“如何跟踪模块的工具依赖性?”。模块Wiki上的常见问题解答。
简而言之,您可以tools.go在一个单独的程序包中创建一个文件,并设置一个// +build tools构建标记,例如:
// +build tools
package tools
import (
_ "golang.org/x/tools/cmd/stringer"
)
Run Code Online (Sandbox Code Playgroud)
import语句使go命令可以在模块的中精确记录工具的版本信息go.mod,而// +build tools构建约束阻止正常的构建实际导入工具。
| 归档时间: |
|
| 查看次数: |
9368 次 |
| 最近记录: |