如何使 Go 模块语义导入版本控制 v2+ 与虚导入路径一起工作
How to make Go modules semantic import versioning v2+ work with vanity import path
我们正在尝试将我们的 Go 代码库迁移到 Go 模块，但我不知道如何让它与虚导入路径一起工作。
和dep
到目前为止，我们的依赖管理工具一直是 dep。我们将在项目根目录中放置一个 Gopkg.toml 文件，并定义一个依赖项，例如：
[[constraint]]
name = "mycompany.com/some-lib"
version = "3.0.0"
如您所见，我们为自己的包使用所谓的 虚导入路径。事实上，我们的代码实际上完全托管在私有 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.
[ 所做的那样=40=]
奖励信息 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 后缀，除非您想将不同的版本路由到不同的存储库。
我们正在尝试将我们的 Go 代码库迁移到 Go 模块，但我不知道如何让它与虚导入路径一起工作。
和dep
到目前为止，我们的依赖管理工具一直是 dep。我们将在项目根目录中放置一个 Gopkg.toml 文件，并定义一个依赖项，例如：
[[constraint]]
name = "mycompany.com/some-lib"
version = "3.0.0"
如您所见，我们为自己的包使用所谓的 虚导入路径。事实上，我们的代码实际上完全托管在私有 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.
[ 所做的那样=40=]
奖励信息 2： 奇怪的是，我们所有项目的第三方依赖项要么不在 go 模块上，要么仍在 v0 或 v1 上版本或仅托管在 github 上，因此我找不到适用的示例。
非常感谢任何见解。谢谢。
Am I supposed to handle every single
/vNroute 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 后缀，除非您想将不同的版本路由到不同的存储库。