如何使Go模块语义导入版本控制v2 +与虚荣导入路径一起使用 [英] How to make Go modules semantic import versioning v2+ work with vanity import path

查看:67
本文介绍了如何使Go模块语义导入版本控制v2 +与虚荣导入路径一起使用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在尝试将Go代码库迁移到go模块,但我不知道如何使其与虚荣导入路径一起使用.

We are trying to migrate our Go code base to go modules and I can't figure out how to make it work with vanity import paths.

到目前为止,我们的依赖项管理工具为 dep .我们将 Gopkg.toml 文件放置在项目根目录中,并定义如下依赖项:

Until now our dependency management tool has been dep. We would place a Gopkg.toml file in our project root, and would define a dependency like:

[[constraint]]
  name = "mycompany.com/some-lib"
  version = "3.0.0"

如您所见,我们对自己的软件包使用了所谓的虚荣导入路径.实际上,我们的代码实际上完全托管在私有git服务器上.
因此,与此同时,我们设置了另一台服务器,该服务器呈现带有存储库信息的HTML元标记.例如:

As you can see, we use a so-called vanity import path for our own packages. In fact, our code is actually hosted on a private git server altogether.
So along with this, we set up another server that renders HTML meta tags with repository information. E.g.:

<meta 
    name="go-import" 
    content="mycompany.com/some-lib git https://mygitserver.com/some-lib"
>

该机制基本上是cmd/go文档中描述的一种机制,远程导入路径.

The mechanism is basically the one described in cmd/go docs, Remote import paths.

因此,使用go模块代替,我有 export GO111MODULE = on 和一个 go.mod 文件,该文件需要根据

So with go modules instead I have export GO111MODULE=on and a go.mod file that requires a dependency according to 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.

Note that the import path has the v3 suffix as required by semantic import versioning. And the some-lib project also has its own go.mod file starting with: module mycompany.com/some-lib/v3.

现在我的问题是,当 go get go build 时,依赖项解析失败,并显示以下内容:
go:mycompany.com/some-lib/v3@v3.0.0:无法识别的导入路径"mycompany.com/some-lib/v3"(解析https://mycompany.com/some-lib/v3?go-get = 1:没有go-import元标记())

当然会发生这种情况,因为我的远程导入服务器处理的是 mycompany.com/some-lib 而不是 mycompany.com/some-lib/v3 .

Now my problem is that when go get or go build the dependency resolution fails with:
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 ())

Of course this happens, because my remote import server handles mycompany.com/some-lib but not mycompany.com/some-lib/v3.

  • go 命令不能自动处理版本化的导入吗?我以为它会查询 mycompany.com/some-lib ,然后自己获取 v3 .
  • 我应该处理远程导入服务器中的每个/vN 路由吗?
  • 如果是这样,我应该在< meta> 标记中写些什么?如果没有,我该怎么办?
  • Isn't go command able to handle versioned imports automatically? I thought it would query for mycompany.com/some-lib and then fetch v3 by itself.
  • Am I supposed to handle every single /vN route in my remote import server?
  • If so, what should I write in the <meta> tag? If not, what should I do?

奖金信息:我看过一些文档和文章,建议基本上在以主要版本命名的目录下复制代码,例如:

Bonus info: I've seen some docs and articles recommending to basically duplicate the code under directories named after major versions, something like:

/               ---> 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 一样,需要从同一位置获取版本.

Or alternatively to maintain separate branches for each major version.
I don't want to do this. And I want to require mycompany.com/some-lib/v3 v3.0.0 or require mycompany.com/some-lib/v4 v4.1.0 based on each client project needs and fetch versions from the same place just as I did with dep.

奖励信息2:足够奇怪的是,我们所有项目的第三方依赖项都不在go模块上,或者仍在 v0 v1 版本或仅托管在github上,因此我找不到适用的示例.

Bonus info 2: curiously enough, ALL our project third-party dependencies either are not on go modules or are still on v0 or v1 versions or just hosted on github, so I can't find applicable examples.

任何见解都将受到高度赞赏.谢谢.

Any insight is extremely appreciated. Thank you.

推荐答案

我应该处理远程导入服务器中的每个/vN 路由吗?

是的.(您已经应该处理可能与存储库中的程序包相对应的所有路径:请参见 https://golang.org/cmd/go/#hdr-Remote_import_paths .)

Yes. (You are already supposed to handle every path that may correspond to a package within the repository: see https://golang.org/cmd/go/#hdr-Remote_import_paths.)

如果是这样,我应该在< meta> 标记中写什么?

您今天编写的东西应该完全相同:相同的路径,不需要/vN 后缀,除非您要将不同的版本路由到不同的存储库.

Exactly the same thing that you are writing today should work: the same paths, with no /vN suffix needed unless you want to route different versions to different repositories.

这篇关于如何使Go模块语义导入版本控制v2 +与虚荣导入路径一起使用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆