如何处理go导入绝对路径和github分支?

dei*_*tch 7 go

围绕此有很多问题,包括为什么您不应该使用import "./my/path"它以及为什么它只能工作,因为某些传统的go代码需要它。

如果这是正确的,那么您如何处理项目的封装,以及如何通过github分支进行封装?在其他每个lang中,我都可以做一个项目的github分支或git clone,所有内容都封装在那里。我如何从go项目中获得相同的行为?

使用go“ hello world”示例的简单示例。

你好

package main

import ("fmt"
    "github.com/golang/examples/stringutil")

func main() {
    fmt.Printf(stringutil.Reverse("hello, world")+"\n")
}
Run Code Online (Sandbox Code Playgroud)

上面的作品很棒。但是,如果我想使用自己的stringutil,它位于子目录中并可以编译为单个二进制文件,那么我仍然需要完整的路径:

package main

import ("fmt"
    "github.com/myrepo/examples/util/stringutil")

func main() {
    fmt.Printf(stringutil.Reverse("hello, world")+"\n")
}
Run Code Online (Sandbox Code Playgroud)

现在,如果有人复制或分叉我的存储库,即使它完全在内部使用,它也直接依赖于“ github.com/myrepo/”

如果要导入20个不同的文件utils/怎么办?每当有人分叉时,我都需要更改每一个?那是很多无关紧要的更改,而且是毫无意义的git commit。

我在这里想念什么?为什么相对路径这么糟糕?如何在不更改数十个文件的情况下派生引用其自己的子目录(及其包)的项目?

Not*_*fer 3

至于不允许相对导入背后的原因,您可以阅读此讨论以了解一些观点:https://groups.google.com/forum/#! msg/golang-nuts/n9d8RzVnadk/07f9RDlwLsYJ

就我个人而言,我宁愿启用它们,至少对于内部导入来说,正是出于您所描述的原因。

现在,遇到这种情况该如何处理呢?

  1. 如果您的分叉只是另一个项目的一个小修复,可能很快就会被接受为 PR - 只需手动编辑 git 遥控器,使其引用您自己的 git 存储库,而不是原始的。如果您使用像 godep 这样的供应商解决方案,它将顺利工作,因为保存它只会供应您的分叉代码,而go get不会直接使用。

  2. 如果您的分叉是一个很大的变化并且您打算保持分叉,请重写所有导入路径。您可以使用它来自动化它sed,也可以使用gofmt -r支持重写正在格式化的代码。

[编辑]我还发现了这个工具,旨在帮助解决这种情况: https: //github.com/rogpeppe/govers

我已经完成了 1 和 2 - 当我刚刚对某个库进行了一个小错误修复时,我只是更改了遥控器并对其进行了修改。当我实际上分叉了一个库而不打算合并我的更改时,我更改了所有导入路径并继续仅使用我的存储库。

我还可以考虑添加一个允许这些东西自动化的供应商工具,但我认为目前没有任何一个支持它。

  • 换句话说,对于企业内部项目管理来说,这是一种很好的理念,但对于协作开源管理来说,并不是一种很好的理念。太可惜了。我真的很喜欢 go 所做的很多事情。这不是其中之一 (3认同)