我们正在尝试将我们的 Go 代码库迁移到 Go 模块,但我不知道如何让它与虚导入路径一起工作。
与dep
到目前为止,我们的依赖管理工具是dep
.我们会放置一个 Gopkg.toml
文件在我们的项目根目录中,并定义如下依赖项:
[[constraint]]
name = "mycompany.com/some-lib"
version = "3.0.0"
如您所见,我们为自己的包使用所谓的虚导入路径。事实上,我们的代码实际上完全托管在私有(private) git 服务器上。
因此,与此同时,我们设置了另一个服务器来呈现带有存储库信息的 HTML 元标记。例如:
<meta
name="go-import"
content="mycompany.com/some-lib git https://mygitserver.com/some-lib"
>
该机制基本上是 cmd/go 文档中描述的机制,Remote import paths .
使用 go 模块
所以用 go modules 代替我有 export GO111MODULE=on
和一个 go.mod
根据 semantic import versioning 需要依赖项的文件:
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: 奇怪的是,我们所有的项目第三方依赖项要么不在 go 模块上,要么仍在 v0
上或 v1
版本或只是托管在 github 上,所以我找不到适用的示例。
非常感谢任何见解。谢谢。
最佳答案
Am I supposed to handle every single
/vN
route in my remote import server?
是的。 (您已经应该处理可能对应于存储库中的包的每个路径:参见 https://golang.org/cmd/go/#hdr-Remote_import_paths。)
If so, what should I write in the
<meta>
tag?
您今天写的完全一样的东西应该可以工作:相同的路径,没有 /vN
除非您想将不同的版本路由到不同的存储库,否则需要后缀。
关于git - 如何使 Go 模块语义导入版本控制 v2+ 与虚导入路径一起工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57908619/