Question

我对golang完全陌生，我想知道为什么许多golang项目以这种方式在其源代码中编写：

import  "github.com/stretchr/testify/assert"

如果这个testify移到了位桶怎么办？

为什么不像其他语言一样下载证词和import testify？

Answer 1

在回答您的问题之前，您需要了解golang管理其程序包和依赖项的方式。

要下载软件包，请使用go get命令。用法示例：

$ go get github.com/stretchr/testify

以上命令将下载testify软件包，然后将其本地存储在work space下，其结构遵循其url（ TL; DR 工作空间路径已注册为$GOPATH env变量）

$GOPATH/src/github.com/stretchr/testify

An explanation from the doc为什么下载的软件包名称将跟随其URL：

Get下载由导入路径命名的软件包及其依赖项。

现在关于您的问题：

为什么许多golang项目直接从GitHub导入？

语句import "github.com/stretchr/testify/assert" 并不意味着该软件包是直接从github网站（通过http）导入的。。它是从您本地的github.com/stretchr/testify下的$GOPATH/src路径导入的。该软件包之前已下载并存储在此处，因此可以将其导入任何项目中。

以下是documentation中有关导入语句的说明：

转到路径（$GOPATH）用于解析导入语句。

还请看下面的一些代码（从我的本地获取）。

$ echo $GOPATH
/Users/novalagung/Documents/go

$ go get -u github.com/stretchr/testify
# package will be downloaded into $GOPATH/src folder using the same structure as the github url

$ tree -L 1 $GOPATH/src/github.com/stretchr/testify
/Users/novalagung/Documents/go/src/github.com/stretchr/testify
├── Gopkg.lock
├── Gopkg.toml
├── LICENSE
├── README.md
├── _codegen
├── assert
├── doc.go
├── http
├── mock
├── package_test.go
├── require
├── suite
└── vendor

因此，如果要导入任何程序包，则必须位于$GOPATH/src文件夹下。

该证词移至bitbucket会怎样？

它对您的本地项目没有影响，因为所需的软件包之前已经下载过。但是，如果要更新它，则可能需要更改包路径以遵循它的新url，例如bitbucket.org/stretchr/testify/assert？取决于新的bitbucket网址是什么样。

但是我不认为证人的所有者会这样做，因为它将破坏很多人的代码。

Answer 2

为什么不像其他语言一样下载证词并导入证词？

某些库会执行此操作（我是说下载），因为Go没有适当的软件包管理，而解决方法是使用一种称为 vendoring 的技术，该技术基本上是为了克隆/从可能存在的位置快照代码，并在导入语句中使用该包结构

该方法的缺点是，您显然会丢失最新更新，直到重复该过程为止，并且不能始终保证签出的代码是稳定的版本

Answer 3

这个问题引起了人们对go导入路径设计的关注。如@xpare所述，go将依赖项带到本地$ GOPATH。但是，OP的问题尚未得到充分解决。

是的，如果github.com/stretchr/testify的作者/维护者将包移到了bitbucket，则将引起问题。由于您的计算机具有依赖性，因此这可能不会对您的计算机造成问题，但是对于想要为该应用程序做出贡献的任何人，都会造成问题。不仅如此，如果构建服务器每次必须拉出依赖关系，也会对构建服务器造成问题。

即使人们不经常从github转移到bitbucket，这仍然是一个令人担忧的问题。当微软购买github时，许多软件包转移到其他提供商。不能保证任何提供者（例如github或其他提供者）都将保持相同的价格，相同的服务质量，相同的功能等。事情不可避免地会发生变化。

不仅如此，作者有时还会将包移动到另一个用户下的github中的另一个位置。这也发生了。

那是个问题吗？是的，尽管go中导入URL的设计允许清楚地指定依赖项，但是缺点是，当程序包移动时，代码必须更改。供应商倾向于帮助使应用程序抵御这些更改，但是如果要更新软件包，供应商则无济于事。

go的设计需要分散的软件包管理。此设计不受诸如npm引起争议的deleting kirk package导致的许多npm应用程序中断之类的问题的影响。因此，如果人们不同意npm哲学，那将是一个大问题。但是，如果人们不喜欢github，他们通常会转移到其他提供程序，并且这些软件包将始终存在（这样做会导致源代码发生更改）。因此，golang不能保证所有软件包名称都是唯一的，因此必须使用完整的导入路径。

每种方法都有其优缺点。不幸的是，这意味着需要完整的导入路径。

为什么许多golang项目直接从GitHub导入？

3 个答案: