我在我的项目中使用goczmq,如下所示:
main.go:
package main import ( _ "github.com/zeromq/goczmq" ) func main() { }
而且,我使用 golang 1.12 和 gomod 来管理我的项目。
看接下来,我使用go mod init xxx, 并且在构建时,它会自动为我下载 goczmq 并将依赖项添加到go.mod,但其中有incompatible。(但对于其他图书馆,我可能会得到类似的东西github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181)
go mod init xxx
go.mod
incompatible
github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181
go.mod:
module pigeon go 1.12 require ( github.com/zeromq/goczmq v4.1.0+incompatible )
从一些讨论(对于其他图书馆),例如this,图书馆所有者似乎应该做些什么来支持 golang 1.12?但在我的情况下,一切都很好,只是incompatible让我有点担心(我的意思是现在一切都很好,但是有一天当我使用我以前从未使用过的 api 时,那里会有隐藏的炸弹......?)
所以我的问题:
我应该担心这个,还是正如预期的那样?
+incompatible 意味着该依赖项的 semver 主要版本为 2 或更高,并且还不是 Go 模块(它的源代码中没有 go.mod)。
+incompatible
go build 或 go test 等标准命令将根据需要自动添加新的依赖项以满足导入(更新 go.mod 并下载新的依赖项)。但是有几种不同的情况会导致不同的版本选择:
未选择加入模块:意味着go.mod在源树中没有
有效的 semver 标签:意味着 repo 使用 git 标签来标记为类似的东西vX.Y.Z
vX.Y.Z
v0/v1 模块:表示主要版本(即 X)的值为 0 或 1,例如 v0.1.0、v1.2.3
然后,它将使用 a pseudo-version,类似于github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181
pseudo-version
v2+ 模块:表示主要版本(即 X)的值 >=2,例如。v4.1.0
然后,它会显示为incompatible,类似于github.com/zeromq/goczmq v4.1.0+incompatible
github.com/zeromq/goczmq v4.1.0+incompatible
然后,它将表现为 1,使用pseudo-version.
然后,它的行为会像 github.com/stretchr/testify v1.3.0
github.com/stretchr/testify v1.3.0
然后,当进口在源代码中,我们需要添加/vN底,例如import "github.com/my/mod/v4",在go.mod它会像github.com/my/mod/v4 v4.1.0
/vN
import "github.com/my/mod/v4"
github.com/my/mod/v4 v4.1.0