如何处理go导入绝对路径和github分支? [英] how to handle go import absolute paths and github forks?

问题描述

与此相关的问题很多，包括为什么不应该使用 import"./my/path" 以及为什么仅在某些旧版go代码需要它的情况下才起作用.

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

使用go"hello world"示例的简单示例.

hello.go

 程序包主要导入("fmt""github.com/golang/examples/stringutil")func main(){fmt.Printf(stringutil.Reverse("hello，world")+"\ n")} 

以上效果很好.但是，如果我想使用子目录中的自己的stringutil并将其编译为单个二进制文件，则我 still 需要完整的路径:

 程序包主要导入("fmt""github.com/myrepo/examples/util/stringutil")func main(){fmt.Printf(stringutil.Reverse("hello，world")+"\ n")} 

现在，如果有人复制或分叉我的存储库，则它直接依赖于"github.com/myrepo/"，即使它是完全在内部使用的！

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

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

解决方案

至于不允许相对导入的原因，您可以从某种角度阅读此讨论: https://github.com/rogpeppe/govers

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

我还可以想到除供应商工具之外的其他工具，这些工具可以自动执行此操作，但是我不认为它们中的任何一个目前都支持它.

There are plenty of questions around this, including why you shouldn't use import "./my/path" and why it only works because some legacy go code requires it.

If this is correct, how do you handle encapsulation of a project and by extension github forks? In every other lang, I can do a github fork of a project, or git clone, and everything is encapsulated there. How do I get the same behaviour out of a go project?

Simple example using the go "hello world" example.

hello.go

package main

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

func main() {
    fmt.Printf(stringutil.Reverse("hello, world")+"\n")
}

The above works great. But if I want to use my own stringutil which is in a subdirectory and will compile to a single binary, I still need the complete path:

package main

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

func main() {
    fmt.Printf(stringutil.Reverse("hello, world")+"\n")
}

Now, if someone copies or forks my repo, it has a direct dependency on "github.com/myrepo/", even though this is used entirely internally!

What if there are 20 different files that import utils/? I need to change each one each time someone forks? That is a lot of extraneous changes and a nonsensical git commit.

What am I missing here? Why are relative paths such a bad thing? How do I fork a project that refers to its own subsidiary directories (and their packages) without changing dozens of files?

解决方案

As for the reasoning behind not allowing relative imports, you can read this discussion for some perspective: https://groups.google.com/forum/#!msg/golang-nuts/n9d8RzVnadk/07f9RDlwLsYJ

Personally I'd rather have them enabled, at least for internal imports, exactly for the reason you are describing.

Now, how to deal with the situation?

1. If your fork is just a small fix from another project that will probably be accepted as a PR soon - just manually edit the git remotes for it to refer to your own git repo and not the original one. If you're using a vendoring solution like godep, it will work smoothly since saving it will just vendor your forked code, and go get is never used directly.

2. If your fork is a big change and you intend to remain forked, rewrite all the import paths. You can automate it with sed or you can use gofmt -r that supports rewriting of the code being formatted.

[EDIT] I also found this tool which is designed to help with that situation: https://github.com/rogpeppe/govers

I've done both 1 and 2 - when I just had a small bugfix to some library I just changed the remote and verndored it. When I actually forked a library without intent of merging my changes back, I changed all the import paths and continued to use my repo only.

I can also think of an addition to vendoring tools allowing automation of this stuff, but I don't think any of them support it currently.

这篇关于如何处理go导入绝对路径和github分支?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！