godep 添加依赖_Godep中的Godep依赖管​​理

godep 添加依赖

Go与许多其他语言的不同之处在于Go具有多种依赖关系管理方法和工具。 Go团队认可的方法涉及在项目文件夹中供应依赖项，并修改import语句以支持新位置。

Godep的工作方式与认可的方法不同……无需修改源代码以支持供应商的导入路径， 而是将GOPATH修改为使用供应商的文件夹。 这是有益的，因为使用go get设置GOPATH ，相同的代码在Godep环境和独立环境中均可工作 。 存在其他依赖关系管理方法和工具，因此请务必仔细阅读它们，并选择适合您的项目或组织的方法和工具。

有关基本的使用说明，请查看Godep文档 。 根据我在Godep上的经验，我将为您简要概述使用它的优缺点以及一些指导原则。

通过@codeship“阅读与Godep合作的利弊”

点击鸣叫

Godep如何运作

一个godep保存命令将复制其整体全部采用进口包从当前GOPATH成./Godeps/_workspace一个vendored工作区文件夹。 这些软件包的列表将与相关版本信息一起存储在主文件Godeps / Godeps.json中 。 这不仅针对您的项目直接导入的软件包，而且针对您的依赖项所导入的任何软件包-本质上是构建项目所需的一切。 您必须添加整个文件夹SCM，并且绝不能以任何方式对其进行手动更改。

使用Godep就像添加普通的Go命令一样简单，例如go test或使用godep命令进行构建 。 这使用临时扩展的GOPATH ，该GOPATH优先处理Godep供应商目录。

$ godep save ./…       # saves your GOPATH to the Godep folder
$ godep go build ./…   # builds using the Godep vendored dependencies
$ godep go test ./…    # tests using the Godep vendored dependencies

从这里开始，如果您对GOPATH进行更改，则将隔离您的项目。

$ go get -u github.com/golang/protobuf/… # update a dependency
$ go build ./…                          # build using standard GOPATH
$ godep go build ./…                     # build using Godep vendored version

Godep更新与Godep保存

有两种方法可以将更改应用于Godep文件夹。 了解每种情况的正确用法将为您节省大量的时间和挫败感。 Godep保存和Godep更新的工作方式非常不同，并以不同的方式更改Godep。 这里要记住的关键是，如果您有任何疑问，请使用godep save 。

godep更新需要一个特定的依赖包，并在你的GOPATH版本更新包的vendored实例。 这将更新更改的文件，添加新文件，删除旧文件以及更新Godeps.json文件中列出的SHA版本。

$ go get -u github.com/golang/protobuf/…
$ godep update github.com/golang/protobuf/…

这不会从依赖关系管理中添加或删除子包，也不会递归更新任何其他依赖关系。 Godeps.json文件中仅列出以前导入的软件包，并且仅更新列出的软件包。

更新整个软件包将更新对子软件包的任何引用； 但是，不会添加新软件包，也不会删除旧软件包。 同样，如果依赖项更新依赖于依赖项堆栈中其他位置的其他更改，则可能会遇到问题。 godep更新仅触摸Godeps.json中列出的与提供的软件包模式匹配的软件包。

相反， Godep保存将整个相关的GOPATH应用于Godeps文件夹，并将根据需要添加/删除软件包。 因为它基于您的GOPATH ， 所以Godep save还可以在应用更改之前检查构建错误和不干净的存储库，从而加强依赖关系的内聚性。

鉴于使用Godep更新的危险（缺少软件包和依赖项），使用godep save更加安全。 满足以下两个条件是唯一可以安全使用Godep更新的情况：

• 目标依赖项的依赖项不需要更新。
• 没有导入添加到目标依赖项或从目标依赖项中删除。

如果依赖关系对您的组织而言是外部的，则可能很难确定正在进行的更改，因此永远不要对任何第三方使用** godep update`更为安全。

与Godep合作的注意事项

除了了解与Godep一起使用的基本命令外，还有许多陷阱。

通过@codeship“了解Godep的基本命令以及陷阱”

点击鸣叫

Godep可以跨项目分散

在从多个源对版本进行依赖的情况下，可以轻松地在同一 Godep环境中以不同的版本表示依赖。

考虑内部代码库ProjectA将ProjectB和ThirdPartyA列为依赖项的情况。 ProjectB和ThirdPartyA都将ThirdPartyB列为依赖项。 如果将ThirdPartyA更新为需要新版本的ThirdPartyB，而ProjectB继续引用旧版本的ThirdPartyB，则ProjectA在Godeps中列出哪个版本？

ProjectA
 ├-- ProjectB
 | └-- ThirdPartyB
 ├-- ThirdPartyA
 | └-- ThirdPartyB

答案很简单。

Godep没有内部冲突解决机制，也无法解决Godep依赖项的要求。 有关使用哪个版本的决定权由开发人员决定； 在这种情况下，ProjectA将使用Godep中最新设置的ThirdPartyB版本。 由于上次写入来自ThirdPartyA的更新，因此ProjectA将引用较新的版本。 当作为依赖项加载时，ProjectB中的任何代码都将引用较新的版本。

这是一个微妙的要点，但它强调了更新依赖项时需要谨慎，以及需要在项目之间同步所有依赖项版本更改。 生成ProjectA时会捕获编译错误，但直到稍后才捕获细微的行为更改。

因此，依赖项更新应同时应用于所有项目。 考虑通过循环脚本更新依赖项，将更改立即应用于所有代码库。

for project in projects
  cd workspace/project
  git checkout master && git pull
  godep restore
  go get -u ThirdPartyB/…
  godep save ./…
  git checkout -b “updating-godeps”
  git commit ./Godeps -m “Updating Godeps”
  git push origin updating-godeps
end

如果多个内部项目需要同步的依赖关系版本，则使用派生的依赖关系版本并将依赖关系控制推送到组织维护的分支要容易得多。 该派生成为对该依赖项进行版本控制的中央控件。 但是，更可能对该依赖项进行更新将导致跨多个项目的重大突破性更改。

有关Go的各种依赖项管理方法和工具的列表，请查看主题的Golang文档 。

Godep仍使用您的本地GOPATH

尽管Godep提供了版本化的GOPATH实例，但它仍使用原始的GOPATH 。 在主GOPATH之前检查供应商的工作区是否有软件包。 通常，这不会引起问题，但是在某些情况下可能会很麻烦。

由于已引用了您的主GOPATH ，因此可能直到开发周期的后期才能捕获缺少的依赖项。 您的GOPATH中很可能有Godep遗失的任何包裹; 这种无缝的回退使得很难确定命令最终使用的依赖版本。 由于此复合GOPATH ，当依赖项版本不兼容时，可能会出现生成错误。 避免此问题并尽早发现缺失的依赖关系的最佳方法是在一次性GOPATH或容器中进行构建。

何时使用Godep

并非每个项目都可能需要Godep提供的广泛的依赖控制。

与基于导入路径的供应商不同，Godep会供应整个依赖关系集，而不管对其版本化的具体需求如何。 这确实意味着，除非先通过GOPATH然后通过Godep进行明确更改，否则将永远不会更新依赖项。

如果您的组织在不同项目之间具有大量公共依赖关系，则可能需要考虑使用分叉的依赖关系模型。 Godep提供了一个本地控制的，可定制的依赖项管理系统。 谨慎使用时，此系统可以支持版本高且可重现的内部版本，尤其是在具有很少共享依赖项的抗变更环境中。

通过@codeship进行“ Godep：Go中的依赖管理”

点击鸣叫

翻译自: https://www.javacodegeeks.com/2015/06/godep-dependency-management-in-go.html

godep 添加依赖