[英]How to make Go modules semantic import versioning v2+ work with vanity import path
我们正在尝试将Go代码库迁移到模块,我无法弄清楚如何使其与虚拟导入路径一起工作。
dep
到现在为止我们的依赖管理工具已经dep
。 我们会在项目根目录中放置一个Gopkg.toml
文件,并定义一个依赖项:
[[constraint]]
name = "mycompany.com/some-lib"
version = "3.0.0"
for our own packages. 如您所见,我们为自己的包使用所谓的 。 实际上,我们的代码实际上完全托管在私有git服务器上。
因此,我们设置另一个服务器,使用存储库信息呈现HTML元标记。 例如:
<meta
name="go-import"
content="mycompany.com/some-lib git https://mygitserver.com/some-lib"
>
该机制基本上是cmd / go docs, 远程导入路径中描述的机制。
所以使用go模块而不是export GO111MODULE=on
和go.mod
文件,根据语义导入版本控制需要依赖:
module foo
go 1.13
require (
mycompany.com/some-lib/v3 v3.0.0
)
请注意 ,导入路径具有语义导入版本控制所需的v3
后缀。 some-lib
项目也有自己的go.mod
文件,从: module mycompany.com/some-lib/v3
。
现在我的问题是,当go get
或go build
,依赖项解析失败了:
go: mycompany.com/some-lib/v3@v3.0.0: unrecognized import path "mycompany.com/some-lib/v3" (parse https://mycompany.com/some-lib/v3?go-get=1: no go-import meta tags ())
当然会发生这种情况,因为我的远程导入服务器处理mycompany.com/some-lib
而不是mycompany.com/some-lib/v3
。
go
能自动处理版本进口命令? 我以为它会查询mycompany.com/some-lib
然后自己获取v3
。 /vN
路由吗? <meta>
标签中写什么? 如果没有,我该怎么办? 奖金信息 :我看过一些文档和文章,建议基本上复制主要版本命名的目录下的代码,如:
/ ---> contains v1.x.y code
|_ main.go
|_ interface.go
|_ go.mod
|_ /v2 ---> contains v2.x.y code
|_ main.go
|_ interface.go
|_ go.mod
或者为每个主要版本维护单独的分支。
我不想这样做。 我想要require mycompany.com/some-lib/v3 v3.0.0
或者根据每个客户端项目的需要require mycompany.com/some-lib/v4 v4.1.0
并从同一个地方获取版本,就像我对dep
。
奖励信息2:奇怪的是,我们所有的项目第三方依赖项都不是在模块上,或者仍然在v0
或v1
版本上,或者只是托管在github上,所以我找不到适用的示例。
非常感谢任何见解。 谢谢。
我应该处理远程导入服务器中的每个
/vN
路由吗?
是。 (您已经应该处理可能与存储库中的包对应的每个路径:请参阅https://golang.org/cmd/go/#hdr-Remote_import_paths 。)
如果是这样,我应该在
<meta>
标签中写什么?
你今天写的完全相同的东西应该工作:相同的路径,不需要/vN
后缀,除非你想将不同的版本路由到不同的存储库。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.