doushi1974 2015-05-18 10:03
浏览 77
已采纳

Golang依赖性管理最佳实践

In Golang, we can specify open source libraries on GitHub as dependencies. For example:

import "github.com/RichardKnop/somelibrary"

This will try to look for a branch based on your Go version and default to master if I understand correctly.

So there is no way to import a specific release of a dependency, e.g.:

import "github.com/RichardKnop/somelibrary#v1.4.8"

What is the best practise to manage dependencies in Go then?

I can see two approaches.

I. Version Modules

Is it to create new modules for major versions with breaking changes?

For example, my Go library could define modules v1 and v2 so then you could do:

import "github.com/RichardKnop/somelibrary/v1"

Or:

import "github.com/RichardKnop/somelibrary/v2"

Based on what you need. Any changes made to v1 or v2 would be required not to break any APIs or working functionality.

II. Forking

This would give you a complete control over a version of external dependency your Go code requires.

For example, you could fork github.com/RichardKnop/somelibrary into your own GitHub account and then in your code do:

import "github.com/ForkingUser/somelibrary"

Then you would have to fork all external dependencies which seems a bit overkill. However it would give you total control over versions. You could keep your forks at a version you know is working with your code and only update forks once you have checked that new releases of dependencies do not break anything.

Thoughts?

  • 写回答

4条回答 默认 最新

  • douweidao3882 2015-06-20 04:15
    关注

    Note: June 2015, the first support for vendoring appears in Go 1.5!

    See c/10923/:

    When GO15VENDOREXPERIMENT=1 is in the environment, this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:

    • If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.
    • When there are multiple possible resolutions, the most specific (longest) path wins.
    • The short form must always be used: no import path can contain “/vendor/” explicitly.
    • Import comments are ignored in vendored packages.

    Update January 2016: Go 1.6 will make vendoring the default.
    And as detailed in the article "MOST GO TOOLS NOW WORK WITH GO15VENDOREXPERIMENT":

    1.6 brings support for /vendor/ to most tools (like the oracle) out of the box; use the Beta to rebuild them.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(3条)

报告相同问题?

悬赏问题

  • ¥15 phython如何实现以下功能?查找同一用户名的消费金额合并—
  • ¥15 孟德尔随机化怎样画共定位分析图
  • ¥18 模拟电路问题解答有偿速度
  • ¥15 CST仿真别人的模型结果仿真结果S参数完全不对
  • ¥15 误删注册表文件致win10无法开启
  • ¥15 请问在阿里云服务器中怎么利用数据库制作网站
  • ¥60 ESP32怎么烧录自启动程序
  • ¥50 html2canvas超出滚动条不显示
  • ¥15 java业务性能问题求解(sql,业务设计相关)
  • ¥15 52810 尾椎c三个a 写蓝牙地址