2013-06-13 03:27
浏览 84


By default, Go pulls imported dependencies by grabbing the latest version in master (github) or default (mercurial) if it cannot find the dependency on your GOPATH. And while this workflow is quite simple to grasp, it has become somewhat difficult to tightly control. Because all software change incurs some risk, I'd like to reduce the risk of this potential change in a manageable and repeatable way and avoid inadvertently picking up changes of a dependency, especially when running clean builds via CI server or preparing to deploy.

What is the most effective way I can pin (i.e. lock down or capture) a package dependency so I don't find myself unable to reproduce an old package, or even worse, unexpectedly broken when I'm about to release?

---- Update ----

Additional info on the Current State of Go Packaging. While I ended up (as of 7.20.13) capturing dependencies in a 3rd party folder and managing updates (ala Camlistore), I'm still looking for a better way...

Here is a great list of options.

Also, be sure to see the go 1.5 vendor/ experiment to learn about how go might deal with the problem in future versions.

图片转代码服务由CSDN问答提供 功能建议

默认情况下,Go通过获取master(github)或default(mercurial)中的最新版本来提取导入的依赖项 找不到对您的GOPATH的依赖关系。 尽管此工作流程非常易于掌握,但要进行严格控制却变得有些困难。 因为所有软件更改都会带来一定的风险,所以我想以一种可管理和可重复的方式降低这种潜在更改的风险,并避免无意间拾取依赖项的更改,尤其是在通过CI服务器运行全新版本或准备部署时。

我可以固定(即锁定或捕获)程序包依赖关系的最有效方法是什么,这样我就不会发现自己无法重现旧的程序包,甚至更糟的是,它意外地损坏了 我何时要发布?


包装的当前状态。 当我最终(截至7.20.13)在第3方文件夹中捕获依赖项并管理更新(ala Camlistore)时,我仍在寻找更好的方法...

< a href =“ https://github.com/golang/go/wiki/PackageManagementTools” rel =“ nofollow”>这里有很多选项。

也 ,请务必查看 go 1.5供应商/实验,以了解如何处理 将来的版本中会出现问题。

  • 写回答
  • 好问题 提建议
  • 关注问题
  • 收藏
  • 邀请回答

5条回答 默认 最新

  • doushi7394 2013-06-13 09:47

    You might find the way Camlistore does it interesting.

    See the third party directory and in particular the update.pl and rewrite-imports.sh script. These scripts update the external repositories, change imports if necessary and make sure that a static version of external repositories is checked in with the rest of the camlistore code.

    This means that camlistore has a completely repeatable build as it is self contained, but the third party components can be updated under the control of the camlistore developers.

    解决 无用
    打赏 举报
  • dongliu0823 2013-06-13 03:47

    There is no built in tooling for this in go. However you can fork the dependencies yourself either on local disk or in a cloud service and only merge in upstream changes once you've vetted them.

    解决 无用
    打赏 举报
  • doudi7782 2013-06-13 05:57

    The 3rd party repositories are completely under your control. 'go get' clones tip, you're right, but you're free to checkout any revision of the cloned-by-go-get or cloned-by-you repository. As long as you don't do 'go get -u', nothing touches your 3rd party repositories already sitting at your hard disk.

    Effectively, your external, locally cloned, dependencies are always locked down by default.

    解决 无用
    打赏 举报
  • drza10046 2013-06-13 07:21

    There is a project to help you in managing your dependencies. Check gopack

    解决 无用
    打赏 举报
  • douzhu6149 2015-01-24 23:03


    I started using godep early last year (2014) and have been very happy with it (it met the concerns I mentioned in my original question). I am no longer using custom scripts to manage the vendoring of dependencies as godep just takes care of it. It has been excellent for ensuring that no drift is introduced regardless of timing or a machine's package state. It works with the existing mechanism of go get and introduces the ability to pin (godep save) and restore (godep restore) based on Godeps/godeps.json.

    Check it out:


    解决 无用
    打赏 举报

相关推荐 更多相似问题