依赖管理、Semver、社区共识

本篇内容是根据2017年2月份#36 Dependency Management, Semver, Community Consensus音频录制内容的整理与翻译

Sam Boyer 加入节目谈论依赖管理、建立社区共识以及其他有趣的 Go 项目和新闻。

Erik St. Martin: 欢迎回到《GoTime》播客的第36期。今天的节目由 Toptal 和 Compose 赞助。

今天的嘉宾有我，Erik St. Martin，Brian Ketelsen 也在这里……

Brian Ketelsen: 大家好！

Erik St. Martin: 还有 Carlisia Pinto……

Carlisia Thompson: 大家好！

Erik St. Martin: 今天我们特别邀请了一位嘉宾，他将为 Go 生态中的依赖管理领域带来急需的知识。他就是 Sam Boyer。Sam，你好吗？

Sam Boyer: 大家好！我很好，你们呢？

Erik St. Martin: 很好，很好。你能先简单介绍一下自己以及你正在做的事情吗？我们可以从这里开始。

Sam Boyer: 好的。我是一个 Go 程序员，信不信由你……

Brian Ketelsen: 什么？！

Sam Boyer: 是的，很疯狂，我知道。

Erik St. Martin: 这 Go 是什么东西？

Sam Boyer: 很奇怪，我听说这和啮齿动物有关……除此之外我知道的不多。我一直对与包管理相关的事情很感兴趣。在我的开源生涯早期，我曾是为 Drupal 项目构建 Git 托管平台的首席工程师。虽然这技术上并不算是包管理，但它非常接近，因为它涉及到源码共享等等。所以，我在处理社区及其共享代码方面有很长的历史。

(译者注: Drupal是一个开源内容管理系统（CMS），用于创建和管理各种类型的网站。它以灵活性和可扩展性著称，非常适合用于从个人博客到大型企业和政府网站的各种项目)

几年前，大概是在第一届 GopherCon（2014年）期间，我认识了 Matt Butcher 和 Matt Farina。我们三人在 2010 年左右曾是同事。当然，他们现在是 Glide 的作者。在第一届 GopherCon 上，我们当时讨论说：“嘿，我们可以一起研究这个包管理领域，确实非常需要有人去做。”不过在2014年，当时公众对这个问题的认知还不是很清晰，也没有太多讨论。

于是他们开始开发 Glide；而我直到后来才真正参与进来……不过从很多不同的人那里，已经有了许多不同的项目，试图解决这个通用问题的至少一部分。

对我来说，大概是在 2015 年 12 月底。我记不清具体是什么触发了我，但我清楚记得我当时非常烦躁，可能是因为我使用的某个工具---可能是 Glide，也可能是 GoDep (该项目2019年2月已经archived)，这并不重要。但我决定：“好吧，我要试着描述一下我们该如何解决这个问题。”于是我花了六周时间写了一篇文章，最后变成了一个 13,000 字的“怪物”，并于去年二月在 Medium 上发布了。

我自豪地说，我从这个世界偷走了五年的生产力，因为读完这篇文章的所有人加起来花了这么多时间。[笑声] 这是我最喜欢的一个角度来看这件事。
事情是这样的……这既是一个复杂的社会问题，也是一个复杂的技术问题。我认为可以公平地说，去年这个问题引发了很多争论。我决定采取的方式是写这篇文章，同时开发一个叫 GPS 的库，它现在是 dep 工具的核心。我想用它作为一种方式，而不是再去开发一个新工具，而是通过它搭建一个平台，让不同工具的维护者能一起讨论，从而推动我们走向更一致的方向，而不是让这种长期存在的分裂继续下去。

我觉得去年 GopherCon 期间，GPS 已经是一个 MVP。然后 Peter Bourgon 决定召集一个包管理委员会。委员会从去年九月开始开会，成员包括我、Ed Muller、Jess Frazelle、Andrew Gerrand。我们每周开两次电话会议，努力完善这个事。

到了去年十月，我们开始在 GPS 的基础上实际实现 dep 工具，并于今年一月初发布。现在我们正奋力将这个工具变为现实，并将其集成到 Go 工具链中。

Erik St. Martin: 我们来聊聊这个……具体说说 GPS。你构建了一个围绕包解决的库，目的是让它可以被多个工具使用……

Sam Boyer: 是的。

Erik St. Martin: 能不能聊聊它的作用和设计动机，以及为什么你选择构建一个库，而不是一个通用的标准工具？

Sam Boyer: 至少有一半的动机是社会性的，而不是技术性的，至少一开始是这样。就像我之前说的，我不想再发布一个新工具了。我脑海里一直有 XKCD 的那种场景---有14个相互竞争的标准。然后有人说：“我知道了，我来创建一个新标准。”结果呢，变成了15个竞争标准。所以我不想重蹈覆辙。

因此，我决定把这个问题下沉到一个库中。我想，如果我能以一种通用的方式解决问题，让不同的工具都能使用它，这样我们就能让这些工具更接近。这是一种弥合工具分歧的方式。

回头来看，我真的很高兴当时这么做了，因为这变成了一个非常有趣的问题---你如何提炼出依赖管理的组件，并围绕它们创建接口……以及到底有哪些依赖管理的组件？

在许多方面，这直接源于我之前写的那篇长文。我试图描述一个好的系统的设计，然后将其抽象化并付诸实践。

Carlisia Thompson: 当我查看 GPS 库（Go Packaging Solver）时，我注意到它的设计语言正如你所说，是为工具构建一个基础。这似乎是它的初衷。那么，随着 GoDep 的推进，这个目标是否仍然存在？因为委员会的目标不就是要摆脱多个工具的局面吗？

Sam Boyer: 是的，是的。这是一个关键问题，我需要解释清楚。我们的确希望这个工具能成为官方工具。需要明确的是，Go 团队目前并没有正式认可 dep 工具---它仍然是实验性的，这绝对没有任何保证。但我们走在正确的道路上，并尽一切努力确保它能够成为官方工具。是的，我们的目标是淘汰目前存在的几乎所有其他工具，并且理想情况下为它们提供迁移路径，这样人们只需要运行一个命令，他们的项目就可以转移到基于 dep 的等价工具上。

Erik St. Martin: 而且，你参与开发的委员会几乎涵盖了当时所有工具的代表，所以理论上它应该能解决每个工具作者为自己工具设计的所有用例……

Sam Boyer: 我想是这样的。我们有一个核心委员会，成员我之前已经提到了。同时，我们还有一个咨询委员会。如果我忘记了谁，我会觉得很糟糕，但我记得成员包括 Daniel Theophanes、Dave Cheney、Matt Farina、Steve Francia。我相信这四个人都在。

可能有一些工具没有被覆盖到，但我们确实尽了很大努力确保覆盖所有用例。目前有一些功能我们还不支持，比如我们还没有像 Glide 那样支持本地镜像，但这些都在计划中。

Brian Ketelsen: 所以并不会阻止 Go 用户继续管理自己的依赖……

Sam Boyer: 这不会发生。我们不能也不应该强迫人们放弃他们习惯的工具；我的经验是，这种做法通常效果不佳。可以说，我们目前的做法有两个方面：其一，我们试图围绕一个工具建立社区共识和势头，以避免无意义的争论；其二，让这个工具足够好，以至于人们不再觉得需要使用他们之前一直使用的工具。

Brian Ketelsen: 完美。我并不是因为想用其他工具才问这个问题，只是因为可能已经有些人不满了，比如“他们硬是要把这个 dep 工具强加给我……”

Sam Boyer: 没错，这不是我想看到的局面。对我来说，那只是毫无意义的争吵，我们没必要为此争论。如果我们能做出一个足够好的工具，就没必要引发这种争论。

Brian Ketelsen: 很棒。

Erik St. Martin: 多种工具的一个有趣问题是，如果没有一个统一的方法去处理这些事情，那么当你有依赖项，而这些依赖项又有它们自己的依赖项，并且它们都使用不同的 vendoring 工具时，要想扁平化依赖树并创建可重复的构建就变得非常复杂了。

Sam Boyer: 这实际上是我在设计 GPS 时最早做出的设计选择之一。GPS 包含“manifest”和“lock”这两个概念，这种双文件系统……我可以详细描述其中的内容，但简单来说，“manifest”主要描述约束，并且只描述你直接依赖的约束；而“lock”是整个依赖图的完整快照，其中没有约束，只有具体的版本，理想情况下是不可变的版本。

GPS 的构建理念是实现工具会传入一个“analyzer”（分析器）的实现，而它实际上只有一个方法：getManifestAndLock。所以每个实现它的工具都可以编写一个分析器，来读取自己特定的 manifest 和 lock 文件。此外，也完全可以把分析器实现为读取其他工具的元数据，只要这些元数据是可转换的。Glide 已经在这么做了---它可以动态地支持四种不同工具的转换。

这意味着我们可以建立一个系统---稍后我会谈谈这是否是个好主意---这个系统可以使 dep 工具能够读取并翻译现有工具的元数据文件，并在求解过程中动态透明地使用这些数据，从而帮助做出求解决策。

对于像 GoDep 这样的工具，它只记录提交 ID 的 SHA1 值，我们甚至可以将其作为建议信息，而不是实际的约束。比如说，“我们倾向于使用这个五层深的复杂传递依赖的特定版本，但如果无法解决，我们可以切换到其他版本。”

问题在于，这是否是个好主意。对于 Glide 来说，这显然是个好主意---有一个分支正在将 Glide 转换为使用 GPS。而这对 Glide 来说很有意义，因为 Glide 永远不会成为唯一的工具；它需要在一个有其他工具共存的生态系统中生存，因此能够动态地从其他依赖管理工具中进行转换是必要的。

然而，对于 dep 工具来说，我们的处境不同。如果我们引入这样的支持，就会鼓励人们继续使用现有的工具，而这并非我们想要的结果。但如果我们不引入它，就无法利用历史代码中已有的元数据……如果我们引入了这些支持，我们就可以动态和智能地与整个 Go 生态系统交互。

Erik St. Martin: 我想指出的是，这需要所有工具至少支持 semver，或者类似的东西。因为如果它们只是一般性地追踪依赖，而不是特定版本的依赖，那么求解会变得很困难。除非像你说的那样，只是作为推荐信息。

Sam Boyer: 是的……版本的种类有很多。你有 semver（语义化版本），分支，修订版本，标签---其中一些是交叉的，有些是并列的，有些则不是……所以，在目前的工具中，只要是记录修订版本或分支之类的功能，GPS 都可以支持并进行转换。除非---我不认为有任何工具这么做了---有工具创建了一种超越版本控制系统本身的新版本形式，否则 GPS 都可以处理并进行等效转换。

因此，我们可以获取所有这些信息。然而，求解过程毫无意义，除非有某种范围的指定。如果某个工具说“这只能使用这个唯一版本”，那么根本不存在求解的问题了。这要么能用，要么失败。所以是的，如果我们要转换的工具不支持 semver，也没有任何范围的概念（我相信目前有两个工具有范围的概念），那么我们也无能为力。这样的解决方案可能会显得过于僵硬。这种决策涉及很多权衡。

不过，好的一面是，我在设计时考虑到了这些权衡，并认识到很难一开始就知道哪个方向是正确的。我优化了这种方式，确保我们可以轻松改变实现方式。我们可以编写代码来从不同工具中吸取数据，并进行实验。只需两行代码就可以决定“是的，我们从其他工具中获取元数据”或“否，我们停止这么做”。至少，这样我们可以通过实验来确定这是否是个好主意。

Erik St. Martin: Brian，你是不是想问点什么？

Brian Ketelsen: 我的问题其实差不多，不过我想从另一个角度问：“如果我们能引导 Go 社区朝一个方向前进，我们会建议大家开始打标签（tag）并使用 semver 吗？”从社区角度来看，什么最合理？我们如何鼓励这样的行为来让所有事情变得更简单？

Sam Boyer: 是的，开始打标签并使用 semver，这会非常棒。Dave Cheney 大约一年前写过一篇 文章，当然这种呼吁已经存在很久了……但没错，现在就开始用 semver 给你的代码打标签吧。即使你目前还没使用这些元数据，仅仅能够针对这些版本就已经是一个进步了。

Brian Ketelsen: 我在 GitHub 上见过很多工具，比如基于 Ruby、Node 或 JavaScript 的工具，它们可以自动打标签和发布 GitHub releases。你觉得如果我们在 Go 的命令里加入类似功能，比如 go tag、go release 和 go increment version，会不会鼓励人们采用？

Sam Boyer: 是的。我们在去年 12 月的 Advent 系列博文中发出过类似的请求，有人已经写了一个工具，不过我很惭愧地说，还没有时间去看。但确实，把这些功能作为工具的一部分可能会非常有帮助。我们之所以还没有完全实现，比如 go release，是因为目前发布的含义是：你打标签并推送它，这取决于你使用的版本控制系统。如果未来我们有类似 npm 或 Crates 的中央注册系统，那么 release 命令可能会将代码发布到该系统。但这又是一个完全独立的领域，我们在 dep 的 issue 队列中对此有过讨论，但还不明确是否会走这条路。

目前真正有价值的是，静态分析可以告诉你应该 bump（提升）哪个 semver 版本。这有助于确保我们正确使用 semver。

Brian Ketelsen: 这有些跑题，但也算是相关的，所以请原谅我的随机思考。今天我们看到的新项目之一是 UpSpin……

Sam Boyer: 是的，UpSpin。

Brian Ketelsen: 是的，Andrew 和 Rob 的分布式存储系统……我想到，使用像这样的基于内容寻址的分布式文件存储，是一种非常有趣的方式，可以用来打标签，并构建一个大规模的分布式存储库。大家对 GitHub 的主要抱怨之一---尽管我们都很喜欢 GitHub---是当 GitHub 宕机时，所有人都受影响。同样的事情也发生在 Rust Crates 和 Ruby Gems 上---当它们的服务器宕机时，所有人都受影响。但如果我们有一个这样的分布式文件存储系统，a）我们会非常酷，因为没人有类似的东西，b）我们可以用 Go 写它。我不知道，这只是我发烧时的一个随机想法，请原谅我。

Sam Boyer: 不，完全没问题……是的，实际上，我在一年前发表文章后，立刻收到 IPFS 社区的评论，他们说：“嘿，我们可以把这个托管在 IPFS。这不是很棒吗？”另一方面，我记不清是谁，但也有人说：“我不希望我的构建失败，因为网络里目前没有足够的种子节点。”所以，你知道，这其中有很多权衡……

不过我确实认为这是一个有趣的方向。实际上，我还开玩笑地跟 Andrew 私下说，“嘿，也许我们可以用 UpSpin 来做你刚提到的事情。”这是个值得探索的方向，也许我们可以试试。

Brian Ketelsen: 很有趣。

Sam Boyer: 坦白说，我对这个问题领域充满了乐观---无论是玫瑰色的愿景还是彩虹般的可能性。我认为我们可以做很多不同的事情，探索使用某种分布式存储来追踪发布版本绝对在“酷东西”清单上。

Erik St. Martin: 好吧，我想是时候进入我们的第一个赞助商广告了。今天的第一个赞助商是 Toptal。

广告段落：

Erik St. Martin: 我们回来了，接着和 Sam Boyer 聊 GPS 工具以及社区正在研究的一些新的依赖管理工作。我们已经讨论了一些关于 GPS 的工作原理和动机……现在我感兴趣的是聊聊 dep 工具本身。它是作为 GPS 的参考实现而创建的吗？还是它也提供了一些现有工具没有的功能？

Sam Boyer: GPS 和 dep 工具真正区别于其他工具的地方在于，它是一个真正的求解器。这意味着我们可以实现一种有用的模式，其中依赖图中的每个项目都可以说：“这些是我依赖的版本的约束”，并且我们可以有两个不同的项目依赖同一个项目---这通常被称为“菱形依赖”---然后我们可以根据两个父项目的约束，计算出可以使用的公共版本，或者说无法计算出任何版本。

这是一个约束求解问题，是 NP 完全问题，非常复杂。但拥有这种基本能力的关键意义在于，它让每个项目的作者可以独立选择“我知道哪些版本可用”。这样，作为引入其他项目的开发者，不需要深入研究所有依赖及其子依赖，避免了远离自己代码领域而做出选择的麻烦。简单来说，它将问题分布到生态系统中每个人身上。

虽然它并不强制我们完全遵守其他项目的依赖版本约束（可以覆盖这些行为），但它提供了一种默认的协作机制。通过求解器，我们可以解决“应该使用哪些依赖版本”这一难题，而没有其他工具能做到这一点。

Erik St. Martin: 是的，我也想问这个问题，因为很多人，尤其是那些使用不常维护的包的人，可能会设置硬性版本约束而不是 semver 范围约束。当你遇到这样的情况，是否可以轻松地说：“嗯，我知道他们要求 1.2，但我完全可以接受 1.2.3。”

Sam Boyer: 是的，现在确实有一个覆盖行为。如果它今天存在，那它今天就能正常工作。不过，我想说的是，我们已经非常努力地让用户体验尽可能简单，这意味着我们尽量精简命令集，也尽量减少用户需要声明的内容。而实际上，这是一个非常关键的设计决定---我会说这是整个系统中最具 Go 特性的部分。虽然 GPS 的设计最初是从 Dart 的 Pub Solver 改编来的，其结构也类似于 Cargo 的求解器，但 Go 和 dep 最独特的地方在于它们的清单文件（manifest 文件）的处理方式。

(

译者注:

    Dart 的 **Pub Solver** 是 Dart 语言的包管理工具中的一个重要组件，它负责解析和解决依赖关系，以确保项目能够正确地使用所需的库和包。

    Pub Solver 的主要功能包括：

    1. **依赖解析**：分析项目的 `pubspec.yaml` 文件中列出的依赖项，并确定每个依赖项所需的版本。

    2. **版本冲突解决**：如果依赖项之间存在版本冲突，Pub Solver 会尝试找到一个兼容的版本组合，以满足所有依赖项的要求。

    3. **锁定文件生成**：生成 `pubspec.lock` 文件，该文件记录了项目中实际使用的依赖项及其版本，确保团队成员或不同环境中使用相同的依赖版本。

    4. **优化依赖树**：在解析过程中，Pub Solver 会尽量减少依赖项的数量，避免冗余，以提高性能和减少包的大小。

    工作流程：

    1. 开发者在 `pubspec.yaml` 文件中定义依赖项。
    2. 运行 `dart pub get` 命令，触发 Pub Solver 进行依赖解析。
    3. Pub Solver 解析依赖关系，解决版本冲突并生成锁定文件。
    4. 依赖项将被下载并添加到项目中。

    Pub Solver 是 Dart 生态系统中确保依赖管理顺畅的重要工具，特别是在大型项目中，它能有效地管理和协调各种库和包之间的关系。

    

    Cargo 的求解器是 Rust 编程语言的包管理工具 Cargo 中的一个核心组件，负责处理项目依赖关系的解析和版本管理。

    Cargo 求解器的主要功能：

    1. **依赖解析**：根据 `Cargo.toml` 文件中定义的依赖项，解析和确定所需的库版本。

    2. **版本冲突解决**：当依赖项之间存在版本冲突时，求解器会尝试找到一个兼容的解决方案，以满足所有依赖项的版本要求。

    3. **生成锁定文件**：创建和更新 `Cargo.lock` 文件，记录项目中实际使用的依赖项及其具体版本，确保在不同环境中能够一致地使用相同的版本。

    4. **优化依赖树**：求解器会优化依赖关系，尽量减少重复依赖，以提高构建效率和减少最终包的大小。

    工作流程：

    1. 开发者在 `Cargo.toml` 文件中声明项目依赖。
    2. 运行 `cargo build` 或 `cargo update` 命令，触发求解器进行依赖解析。
    3. 求解器分析依赖关系，解决版本冲突并更新锁定文件。
    4. 所需的依赖项将被下载并添加到项目中。

    Cargo 的求解器能够有效管理 Rust 项目的依赖关系，确保开发者可以专注于编写代码，而无需担心依赖的复杂性。

)

在其他系统中，manifest 文件既声明了约束（constraints）的概念，也声明了需求（requires）的概念。你必须在 manifest 中列出某些内容，这样它们才能出现在依赖中，并且 manifest 文件还决定了这些内容的版本范围。而在 dep 中则完全不同。决定某个依赖是否出现的因素是导入图（import graph）。我们会静态分析代码（因为这是 Go，我们可以做到这一点），通过分析看哪些导入（import）存在，这决定了依赖是否会出现。而将一个约束（constraint）放入 manifest 中的作用仅仅是缩小可以使用的版本范围。但关键点在于，这意味着你可以继续按照你一直以来的方式编写代码---写代码，写导入语句，然后它就能正常工作。你不需要再去摆弄一个额外的文件。

Brian Ketelsen: 我讨厌摆弄文件（笑）。所以我要再强调这个问题（毕竟我就是这样的人）……这个工具听起来非常棒，我必须承认，GopherCon 的网站代码（在 GitHub 上）现在已经用 dep 做了 vendoring。当我第一次使用它的时候，它运行得很完美。我没有遇到任何问题，它就是“开箱即用”……

Sam Boyer: 酷！

Brian Ketelsen: ……所以，这点值得称赞，考虑到它是个新工具。但我觉得，除非人们开始打标签并发布正式版本，即使有了官方的 dep 工具，我们依然会处于一片混乱的“西部荒野”中。

Sam Boyer: 是的，我认为即使如此，情况也会有一些渐进的改善。虽然我们有一些可能的解决方案---嗯，我觉得我们确实取得了一些进步，但大部分情况下，你说得对……如果人们不发布正式版本，我们也无能为力。这也是为什么，从很早的时候开始，我就觉得仅仅推出另一个工具并不是个好主意。我认为，尝试让大家聚在一起，建立社区动能和共识是非常重要的，因为要让整个生态系统真正运行良好，需要很多不同的人配合。打标签发布版本是第一步。

Brian Ketelsen: 这让我想起 Dave Cheney 的提议（是大约一两年前的事？），当时他建议 Go 官方采用一个版本控制标准。社区的反应大多是“为什么要这样做？”但一如既往，Dave 的想法是前瞻性的。可惜的是，我们在这方面落后了。即使是像 Nim 和 Rust 这样的较新的语言（比 Go 还年轻），它们几乎本能地内置了版本控制的概念，而 Go 则完全依赖于 Git 或其底层的版本控制系统来处理版本控制。我对此感到失望。

Sam Boyer: 我对那段漫长而痛苦的讨论的看法是，我们遇到了“先有鸡还是先有蛋”的问题。在没有一个真正有效的工具支持 semver（语义化版本）之前，人们没有理由开始使用标签；而在没有人打标签发布版本之前，也没有理由去编写一个工具。所以我们陷入了一个恶性循环。这也是为什么我们认为，所有这些问题中，唯一可以由一个人或一个小组独立解决的问题是创建一个功能强大且稳健的工具。这可以解决问题的一半，剩下的就是推动社区的采用。

Brian Ketelsen: 那如果我们能给某人一个平台，比如 GopherCon 的舞台，面对 1,500 人的现场观众，并直播到全世界，你觉得我们能促成一些改变吗？

Sam Boyer: 我觉得我们能促成一些改变。

Brian Ketelsen: 有意思。不是说我们真的能提供这样的平台，只是说假设一下……[笑声]

Sam Boyer: 听起来完全是个假设，完全不像我们生活的这个现实世界，对吧。

Carlisia Thompson: Sam，我想请你谈谈 vendor 目录。我正在看 Ed Muller 的博客文章《I can haz downtime》。他在文章中描述了如何使用 dep ensure，它基本上会创建一个 vendor 目录，这也是大多数人现在的做法。如果我们不打算有一个中心化的仓库来存储不同库的版本，这样做确实有意义。那你能告诉我们这个过程会如何运作吗？它会是什么样子？和现在人们的做法相比，需要做哪些改变？

Sam Boyer: 我认为磁盘上的文件结构实际上不会有太大的变化。我们仍然需要一个 vendor 目录，这种语义不会很快改变。值得注意的是---这一点至少在某些问题讨论中提到过---你应该把 vendor 目录当作一个实现细节，而不是最终目标。这是一个相当长远的事情，所以我不想过多纠结，但我们认为有可能实现一个替代方案，不需要将文件放入 vendor 目录，也不需要不断在磁盘上交换这些文件。我们认为这种解决方案可能会更优雅。唯一的缺点是，它可能不再存储在你的代码仓库中，这意味着你可能会遇到像 “left-pad” 式的失败---如果上游消失了，你可能无法重新构建……这是一个真实的顾虑。

Erik St. Martin: 这是一个新的动词吗？我们以后就叫它“left-padding”了？

Sam Boyer: Left-padding……我在一些演讲中确实把它当作动词用过，所以我觉得算是一个动词了。Carlsia，这回答了你的问题了吗？

Carlisia Thompson: 是的，那 vendor 目录会被扁平化吗？

Sam Boyer: 会。是的，总是会被扁平化，而且是非常彻底的。如果你在 vendor 目录里放了一些工具没有放进去的东西，工具会直接把它删除，完全不会道歉。

Erik St. Martin: 这样也好，因为人们喜欢在 vendor 目录里乱改东西。

Sam Boyer: 不，这点绝不妥协。对待 vendor 作为易变目录的唯一问题是与代码生成相关的一些事情。我在过去一年中看到了一些 Glide 的相关问题……我记不清具体问题了，但我有个清单可能包含这个问题。我有点担心，如果你的项目需要在 vendor 目录中进行代码生成，而你依赖的库需要在自己的目录结构中完成本地代码生成，这可能会导致糟糕的情况。但我认为这基本上是一个我们需要明确的设计问题：“如果你的项目需要代码生成，请设计成可以在其他位置生成，不要依赖在你自己的目录树中生成。”坦白说，如果我们尝试把 vendor 当作不可变目录，维护起来会困难得多。

Carlisia Thompson: 我不想跳得太远，也不知道你能不能回答这个问题，但我们什么时候能用到这个工具呢？[笑]

Sam Boyer: 对，这确实是最重要的问题，对吧？委员会和很多人都在讨论，我们也和 Russ 讨论过。目标是---我正在制定一个路线图，本来希望今天能发布，但我还在做一些调整，并和委员会的其他人核对，不过它应该会在接下来的一周左右发布。我们需要稳定 manifest 和 mod 文件，需要稳定命令集本身，还需要定义和实现一个基本的安全模型。

其他工作也很重要，但我们可以在合并到工具链后继续改进。这将是一个艰难的过程。尽管它现在在 GitHub/golang/dep，这并不意味着它已经被官方认可或注定会进入工具链。我们还有很长的路要走，需要很多人的帮助才能真正实现这一目标。不过，根据这个路线图，在理想情况下，最好的世界里，你在 Go 1.10 中获得的工具链将包括修改后的 dep，并成为新的标准。

Erik St. Martin: 是啊，我觉得只要在 GitHub 上的东西就是“生产级”的了，所以你不应该把它放在那里。[笑声]

Sam Boyer: 你和世界上其他一半人都这么认为。所以这很公平……我们确实等了一段时间才发布这个工具。我们希望它至少是可运行的，尽管有大大的警告：“不要提交这个工具生成的 manifest 和 lock 文件！”但即便如此，已经有人提交了，包括委员会中的人，所以我也没什么可抱怨的。

Carlisia Thompson: 那 1.10 的发布日期定了吗？

Sam Boyer: 应该是今年年底。

Carlisia Thompson: 酷。

Erik St. Martin: 我在试着回忆他们的发布周期……一个是在八月，另一个是---我记不清了。

Sam Boyer: 应该是明年这个时候。

Brian Ketelsen: 抱歉，我刚才静音了……是 2018 年 2 月，因为我们是六个月的发布周期。

Sam Boyer: 明白了。

Carlisia Thompson: 说到帮助，能告诉我们人们如何参与这个过程吗？比如，人们在动手之前是否需要先提交 issue？因为他们怎么知道有哪些事情需要做？你有一个流程吗？有没有人领导这个流程？从一开始就需要人吗？

Sam Boyer: 答案是：以上所有问题的答案都是“是”。我需要所有可能的帮助，这会很棒。我们需要人来测试工具，需要人来写文档，需要人帮忙解决设计问题，也需要人帮助项目管理和处理任务队列。所有这些方面我们都需要帮助。

我正在努力发布的路线图旨在提供一个总体视图，让人们可以阅读后说，“好吧，我知道这个项目的方向，也知道我可以在哪些方面贡献力量。”从那里，我们在 GitHub 上有“Help wanted”和“Good first PR”的标签，你可以通过这些标签找到对应的任务。我们正在努力为新手提供一个清晰的入口，让他们能高效地参与进来。如果你还是不知道从哪里着手，可以加入 GopherSlack 的 vendor 频道，找我聊，我们会找到解决办法。

Carlisia Thompson: 对于想要开始帮忙的人来说，这是联系你的最佳方式吗？

Sam Boyer: 是的。目前有三种主要方式可以参与：

1）直接安装工具，在一个项目上运行 dep，试试看，遇到问题或者有疑问时，提交一个 issue……我指的是，现在这个工具已经足够可用了，你真的可以试试；如果遇到问题，只需要提交一个 issue 就行。我保证没人会对你发火。

2）加入 vendor 频道，提出问题。

3）查看路线图，从路线图中找到相应的重点任务和具体的 issue，循序渐进地参与。

Carlisia Thompson: 很好。

Erik St. Martin: 你对 GoDep 的未来怎么看？你觉得当社区在 semver（语义化版本）和类似问题上达成共识，并对 dep 工具有所了解时，如果它作为 Go 1.10 的一部分发布，社区会在正式发布前就已经大部分接受它了吗？还是你认为 Go 的正式发布会成为推动社区采用它的契机？你怎么看待 dep 工具的未来？我总是想称它为 “GoDep”，可能是因为最终这个工具的命令会是 go dep，对吧？

Sam Boyer: 嗯，最终，“dep” 这个词会被去掉。它会变成类似的命令---现在你用的是 dep init 和 dep ensure，最终可能会变成 go init 和 go ensure。这是目前的计划。我们在委员会中讨论了很多关于命名的问题，尝试了一些其他的名字，但最终因为种种原因没有采用。

我认为未来的发展会是两者的结合。一方面，我们会非常努力地推动工具的发布，给社区足够的时间来测试它。我们的第一个主要里程碑是稳定 manifest 和 mod 文件。一旦我们完成了这部分工作，人们就可以开始“正式使用”这个工具了。我们想要保证的是，一旦这些文件被稳定下来，即使将来工具被集成到 Go 的工具链中，它们也不会再发生变化。所以，你的文件应该是向前兼容的，或者……这就是开发包管理工具的难点……我已经不知道时间的方向是怎样了。 [笑声]

我总是想着代码历史是向后回溯的，而工具的发布是向前推进的……这真是个奇怪的状态。不过，只要我们达到稳定点，你就可以提交你的 manifest 和 lock 文件，即使回到旧版本，未来的 Go 工具链也能正常使用这些文件。

我希望到那个时候，很多人已经有机会试用过这个工具了。dep 将以单独工具的形式存在一段时间，同时也希望在整个发布周期的大部分时间里作为工具链的一部分存在，这样人们就有机会在这两种情况下都进行尝试。然后，我们会正式推出它。

我知道有一些关于是否要用功能标志（feature flag）隐藏它的犹豫，因为这在 Vendor 的实现上变得有些复杂，但我们还需要再观察……显然，这里有很多需要考虑的事情。这个工具涉及到很多方面，所以我们现在能做的就是继续向前推进，尽可能修复所有的 bug，希望我们的设计基本上是合理的……对，就是靠老式的勤奋和开源精神。

Carlisia Thompson: 这确实是很多工作。

Sam Boyer: 是的。

Erik St. Martin: 我觉得大多数项目都是这样的，每个人对于这些工具的运作方式都有自己的看法；我们来自不同的背景，现在人们在实际使用中有多种不同的依赖管理方式……但我认为，现在所有从事这些工具开发的人之间大体达成了共识，这说明了很多问题，我觉得在这个基础上继续推进是相对容易的。

Sam Boyer: 是的，这确实是 2016 年的大部分工作---让所有人达成一致。我无法形容大家齐心协力的场景有多让我感到欣慰。这是一个艰巨且长期的努力，但无论是用户还是工具开发者，大家都齐聚一堂，将我们带到今天这个位置，我真的非常高兴。

Brian Ketelsen: 太棒了。不得不说，Go 社区真的很棒。

Sam Boyer: 我对此无话可说。

Brian Ketelsen: 如果你敢说不是，我们会嘲笑你。 [笑声]

Sam Boyer: 你们嘲笑得有理。

Erik St. Martin: 好的，说到这里，我觉得是时候进入我们今天的第二个赞助商广告了。今天的第二个赞助商是 Compose。

广告时间:

Erik St. Martin: 好的，我们回来了，继续和 Sam Boyer 聊天。我们刚刚讨论了依赖管理工具的相关内容……大家想不想聊聊一些项目和新闻？我们最近一周有没有看到什么有趣的东西？我记得你们提到过 UpSpin……我想节目还剩几分钟时间，所以……

Brian Ketelsen: UpSpin 绝对是一个大项目。如果你还没见过它，它是一个用 Go 编写的大型项目，由 Rob Pike 和 Andrew Gerrand 等人开发。它有很多复杂的分布式存储机制，但说到底，它的核心理念是你的内容可以通过一个一般是你的电子邮件地址的键来进行寻址。这是一个非常有趣的项目。我尝试安装过，但卡在了某些地方，所以放弃了，暂时搁置了。今天我们列表里的东西几乎每一个我都玩过，这很有趣。

Sam Boyer: UpSpin 帮助发现了 GPS 中的一个罕见 bug。

Brian Ketelsen: 哇，这很酷。

Erik St. Martin: 真的吗？

Sam Boyer: 是的。其实也不算特别罕见……如果你从 package A 的测试中导入了某些东西，然后 package B 又导入了 package A 的内容，这是完全合法的；这不是一个循环导入，因为你并没有从 package B 导入 package A 中测试部分的内容。但我现在用于处理这些问题的模型没有区分这些导入来源的概念，因此它错误地认为 UpSpin 有一个实际不存在的循环导入，结果丢弃了 UpSpin 中大约三分之二的内容。

Brian Ketelsen: 是啊，这种事情会发生。做菜总要打破几个鸡蛋。

Sam Boyer: 这是真的。我们最终会修复它的……

Erik St. Martin: 顺便提一下，如果有人还不知道，Go 1.8 上周发布了……

Brian Ketelsen: 是的，就在我们节目录制期间发布的。

Erik St. Martin: 没错。当时 Brian 开玩笑，说博客文章和推文是在我们录制节目时发出来的……他说：“哦，他们就等着我们录节目呢。” [笑声]

Carlisia Thompson: 所以我们可以来宣布它……

Erik St. Martin: 所以，有一些问题已经被发现了，而且他们已经在修复了。其中一个问题非常有趣……基本上，它涉及到 SSA（静态单赋值）优化的依赖性和执行顺序的问题。比如说，在一个循环里，如果你使用了 Atomic 包，它实际上会把它优化掉。不过看起来这个问题已经被修复了，这太棒了。

这真的很有趣，因为我觉得随着我们继续深入研究这些东西，我们可能会遇到更多的问题，但 SSA 还是会非常厉害。

Brian Ketelsen: 我特别喜欢看到大家在 Twitter 上发布的那些 Go 1.8 垃圾回收时间对比 Go 1.7 的图表。这让我想起以前当新的 Mac OS 出来的时候，人们总会开玩笑说："感觉速度变快了"。而 Go 真的就做到了这一点。我太喜欢了，这让我非常开心。

Erik St. Martin: 是的，这也是我非常喜欢 Go 的原因之一---只要你继续写符合 Go 风格的代码，它就会帮你优化得更快，你根本不需要花太多心思去管这些事情。我还看到一篇帖子，我也把它放到了我们的节目文档里，Josh Bleecher Snyder 提到了 1.9 中他们想要在接口优化方面做的一些事情，基本上是强制分配内存。这是因为接口内部其实是通过指向值的指针来表示的。他们计划对这种机制进行一些优化，而这似乎是从大多数日志包的运作方式中引发的。这就是整个事情的起因。我们会把这个链接放到我们的节目笔记里。

你呢，Sam？最近有什么有趣的东西在你关注的范围内吗？

Sam Boyer: 实话说，我现在完全专注于依赖管理的问题，别人跟我说“嘿，有件事情正在发生”，我就会想，“哦，我的工作之外原来还有世界存在啊……”因为我完全沉浸在自己的事情里。给我点时间，我想想看。

Erik St. Martin: 你不用勉强自己哦。我们做这个节目的一部分是聊聊我们最近接触到的东西或者正在玩的东西。Brian 在几期节目之前提到过一个叫 Wuzz 的东西，这是一个非常酷的 TUI（文本用户界面）工具，可以用来代替 cURL，适合那些不想记住所有参数的人。

我这周发现了一个类似的东西，叫 HTTPLab。

Brian Ketelsen: HTTPLab 是不是那种像服务器端的……它和 Wuzz 相反吧？它会收集请求，你可以修改响应然后再发回去？

Erik St. Martin: 是的。

Brian Ketelsen: 噢，我看过这个，感觉好酷。

Sam Boyer: 听起来很有意思。

[狗叫声]

Erik St. Martin: Dunkin 又开始了。

Sam Boyer: 我最近在一个客户项目中第一次真正需要类似的工具……我用了一个拦截 HTTP 请求并处理它们的工具，最后用了 mitmdump 和 mitmproxy。不过我觉得它可能不支持实际修改东西，但差不多是这个方向的东西。

Erik St. Martin: 是啊，有好几种类似的工具，这取决于你需要在哪一端操作。在信息安全领域，很多人会用 Burp Suite 之类的工具来拦截请求，在请求的过程中拦截并修改它们。而我猜 HTTPLab 是做相反的事情，捕获响应然后修改它再发回去。

Sam Boyer: 是的。

Erik St. Martin: Carlisia，你呢？

Carlisia Thompson: 我只是想提一下 Sourcegraph 最近发布了一篇关于如何实现代码智能的博客文章。我没有完整地看完，只是大致浏览了一下，但看起来很酷。我是 Sourcegraph 的超级粉丝，我觉得这篇博客主要是让大家了解他们是怎么做的。如果你还没用过 Sourcegraph，你绝对应该试试，因为它真的很棒。它会让你的工作流程更高效、更快捷。我听上去像个销售人员了吧。 [笑]

Erik St. Martin: 我觉得 Carlisia 应该在拿广告费了。 [笑]

Carlisia Thompson: 也许吧……[笑] 不，我没有。

Brian Ketelsen: “我不仅是代言人，我还是会员！” [大笑]

Erik St. Martin: 我很喜欢他们的浏览器扩展……尤其是在你想找一个库的用例时，真的非常方便。

Carlisia Thompson: 是的，没错，我经常为此用它。

Erik St. Martin: 这周对分布式工具来说也挺有意思的。Brian，你提到了 UpSpin，不过还有两个很酷的工具: Rook，它其实已经存在一段时间了，这是一个用 Go 写的分布式存储系统。还有一个新工具我之前没见过，叫 Meshbird。我还没有玩过，但从他们在 GitHub 上演示的内容来看，做分布式网络真的很酷。

Brian Ketelsen: 我玩过了，我无法撒谎。它的确如预期那样运行。十年前有一个工具……叫什么来着？我完全想不起来了，但它是设置 VPN 最简单的方法。

Erik St. Martin: 哦，像 Mesh，还是……Mosh？

Brian Ketelsen: 后来被 Citrix 或类似的公司收购了，然后就消失了。不过……我跑题了。Meshbird 的工作方式和那个差不多。你只需要在两台机器上启动守护进程，提供一点信息，就可以建立一个 VPN。

Erik St. Martin: 你说的不是 Mosh 吧，那是一个移动终端。

Brian Ketelsen: 不，不是……有一个应用程序，你可以在 VPN 链中的所有服务器上运行它，它会在它们之间建立一个安全隧道，完全在用户空间运行，还有 Windows、Mac 和 Linux 客户端。当时我在工作时，我还能连到家里的 VPN，无论中间有什么阻碍，或者谁试图阻止你，它都能正常运行。

Erik St. Martin: 真不错。

Brian Ketelsen: 我就是想不起来名字了……不过它被收购后就消失了。

Erik St. Martin: 我还在试图搞清楚 Meshbird 的 logo 是什么。

Brian Ketelsen: 哦，我想起来了，是 LogMeIn 收购了它。这可能是最简单的线索。Slack 快点告诉我答案吧。Hamachi！对了！Paulo Pierra，干得漂亮。就是 Hamachi。

Erik St. Martin: 我们现在连事实核查都不用自己做了。

Brian Ketelsen: 是啊，这太棒了，就像有了自己的后援团队一样。等等，我从控制室听到消息, 就是 Hamachi VPN。

Erik St. Martin: 就像你戴了个耳机，正在直播新闻……[大笑]

Brian Ketelsen: 是啊，我超喜欢 Hamachi。我当时疯狂地用它。那是美好的旧时光，我还是个孩子的时候。

Erik St. Martin: 哦，还有一个提案我也想提一下……最近 Fuzzing 越来越流行了，实际上有一个很酷的工具用来 fuzzing 系统调用，这非常有趣。但让我兴奋的是……我记得是 Brad Fitzpatrick 提出的一个提案，想把 fuzzing 添加为测试和基准测试的一级功能，这真的很酷。

Brian Ketelsen: 太棒了。其实目前在测试子包里有一个类似 fuzzing 的东西，但它并不是完整的 fuzzing，只是有点像 fuzzing。

Sam Boyer: 是 Quick 包吗？

Brian Ketelsen: 对。

Sam Boyer: 是的，我早些时候读过那个 issue，他们试图把 Dimitri 的工作融入到 testing/quick 包里，但确实还存在一些问题。不过，如果 fuzzing 能和其他工具链结合起来，那就太棒了。我很喜欢思考 fuzzing，因为不仅 fuzz 这个词很好玩，我每次想到 fuzz，都会想到 American Fuzzy Lop)，这是有史以来名字最棒的软件。

Erik St. Martin: 确实有趣，因为很多 fuzzing 工具的名字都很搞笑。市面上有太多 fuzzing 工具了……而且 fuzzing 本身也很有趣，因为它的实现方法有很多种。有些工具会随机发送垃圾数据，试图引发崩溃；也有些工具使用机器学习的策略，尝试给它一些正常的请求，然后它会不断变异这些请求，直到找到能引发问题的坏请求。

Sam Boyer: 这真的很经典。我喜欢 fuzzing，因为它的有效性恰好说明了一件事：人类写代码真的很糟糕……

Brian Ketelsen: 是的，程序员不值得被信任。

Sam Boyer: 是的，这其实是我编程世界观中最基础的一个信念---我们人类不擅长写代码。所以我真的希望 fuzzing 能加入官方工具链。

Erik St. Martin: 不幸的是，目前我们似乎没有其他选择。如果我们需要写软件来写软件，那这个软件本身也会很糟糕。

Brian Ketelsen: 没错。在机器接管之前，我们就已经完蛋了。而在机器接管之后，这一切就无所谓了。

Sam Boyer: 你说得对。想象一下，我们现在连自己写的软件都不太明白，以后只会更糟糕。

Erik St. Martin: 是啊，我已经完全跟不上软件世界的变化了。让我高兴的是，现在有人开始写工具来检查我们愚蠢的错误，比如静态分析和模糊测试等等，这些都很棒。

Brian Ketelsen: 如果你看看 Go 的工具链，我们在开发者生态系统方面比几乎所有其他语言都领先很多。我们有静态检查工具，有错误检查工具……语言本身还为开发者编写酷炫的工具提供了便利，这些工具能帮助我们写出更好的、更少 bug 的软件。Go 在把这些工具直接集成到 Go 命令中做得非常出色。我们真的领先大多数语言不止一个时代，我真心喜欢这一点。

Erik St. Martin: 是啊，很多静态分析工具直接内置在标准库里，这让开发自己的工具来检查常见错误变得非常简单。而很多语言都没有这样的功能---编译器逻辑是完全分离的，普通用户无法使用。

Brian Ketelsen: 这真的很棒。

Sam Boyer: 甚至连依赖管理方面也提供了机会。我们现在讨论的内容之一---也许以后我们会探索---不仅仅在决定某个版本是否可接受时进行版本约束检查，还可能做一些类型检查，甚至其他检查。

Brian Ketelsen: 直接分析源代码，看看签名是否没有改变……这样可能就没问题了。

Sam Boyer: 是的，这些事情至少是值得探索的。

Erik St. Martin: 我还需要一个工具来帮我检查语义版本（semver），比如说，“嘿，这段代码显然已经不同了，但你还想用同一个版本号。”

Sam Boyer: 没错。

Brian Ketelsen: 哦，等等，我快忘了名字了……某个叫 Bradley 的人在澳大利亚写了这样的工具。

Sam Boyer: [听不清，00:55:56.24]

Brian Ketelsen: 是的！他写了这个工具。

Sam Boyer: 是的，他写了一个，还有另一个类似的工具。但他至少六个月前就写了。

Erik St. Martin: 看，这就是我有多脱节。

Brian Ketelsen: 这也证明了我的记忆力有多差。

Sam Boyer: 哈哈，说得好。

Erik St. Martin: 好吧，那我们来做 \#FreeSoftwareFriday 吧？

Brian Ketelsen: 当然了，没有它这节目就不完整了。

Erik St. Martin: 对的。Sam，给你解释一下……基本上，我们每期节目都会做一个叫 \#FreeSoftwareFriday 的环节。很多开源项目除了被人抱怨或者提问题之外，基本上得不到什么关注。所以我们每期节目都会花点时间，为某个开源项目呐喊助威。这个项目不一定非得是用 Go 写的；它甚至不一定是个项目，也可以是某个人……但就是想为社区做的事情表示感谢，展示我们的认可。如果你有觉得很酷的东西可以分享。如果没有也没关系，我们会先从 Brian 开始，给你点时间想。

Brian Ketelsen: 好，这周我要分享的项目挺有意思的。如果你用过 Google Hangouts，你会知道这个软件的功能。这是个叫 Jitsi-meet 的项目，基本上就是一个可以自托管的 Google Hangouts，它基于 WebRTC 技术，在后台使用了各种疯狂的东西，比如 XMPP 服务器、视频桥接等等。我这周刚刚安装了它，结果让我大吃一惊，质量非常高。我和 Bill Kennedy 进行了视频会议，当时他在印度，感觉他就像在隔壁房间一样, 没有延迟，音视频速度很快……效果非常棒。所以如果你在找一种自托管的视频会议、网络研讨会或会议的解决方案，Jitsi-meet 非常不错，而且它是完全开源的。

Erik St. Martin: 你知道我觉得这个项目有趣的地方是什么吗？听听我和 Brian 的历史……多年前我们刚认识的时候，Brian 是我的老板，他差点因为我在他电脑上安装了 Node 而把我开除了。[笑] 而那软件显然是用 Node 写的。

Brian Ketelsen: Jitsi-meet 不是用 Node 写的。它的一些部分是用 Erlang 写的，有些是用 Python 写的，还有些是 JavaScript 的部分……而且我并没有试图开除你，我只是威胁说如果你再在我的电脑上安装 Node，我就把你开除。[笑]

Erik St. Martin: 那你呢，Carlisia？

Carlisia Thompson: 是的，我发现了一个非常酷的工具。它是用 Go 写的，叫 gcli。这是一个 CLI 生成器，特别酷……简直难以置信。基本上你运行一个命令行命令，其中一个参数是你想用的 CLI 框架的名字，然后它会输出一个完整的目录结构，并且组织得非常好。我很喜欢它已经为你准备好了测试文件，甚至还有一个 readme 文件。现在我看到它还生成了一个 version.go 文件。所以你传入 CLI 框架的名字，还可以传入你想要的命令，然后它会为每个命令生成一个文件和相应的测试文件。真的很酷。

Erik St. Martin: 所以它会为你生成一个脚手架？

Carlisia Thompson: 是的。

Brian Ketelsen: 我喜欢代码生成器。

Erik St. Martin: 是啊，更酷的是它让你选择自己的 CLI 框架。它支持 Mitchell Hashimoto 的 CLI 工具，我还看到似乎有 Cobra……也许我弄错了。

Brian Ketelsen: 是的，Cobra……太棒了。

Carlisia Thompson: 它支持 Codegangsta、Mitchell 的 CLI，还有一个叫 Go Commands 的工具，但我觉得它是用于标准库的。

Erik St. Martin: 哦，酷。

Brian Ketelsen: 如果他们没支持 Cobra，那他们就做错了。

Carlisia Thompson: 这里没有列出 Cobra。

Erik St. Martin: 我相信他们接受 pull request。

Brian Ketelsen: 我也相信……这就是开源的运作方式。

Sam Boyer: 真正的开源。

Erik St. Martin: 那你呢，Sam？有什么人或项目想要致敬一下吗？

Sam Boyer: 其实我最想致敬的不是某个具体的项目，而是那些写文档的人。

Erik St. Martin: 无名英雄……

Sam Boyer: 是的，真的是无名英雄。很容易花很长时间去开发某个东西,这是知识诅咒的问题。你会忘记自己对写的东西知道多少，同时很难站在其他人角度去理解他们要如何使用它。软件的存在固然重要，但如果我们不知道怎么用，那就毫无意义。

这些人花时间研究如何为别人翻译和解释这些内容。他们是开源世界的纽带，但人们却常常忽视它。所以我要向任何编写文档的人，无论是作者还是贡献者，致敬。

Carlisia Thompson: 这让我想起 Katrina Owen 最近发的一条推特（几周前），大意是：“我不明白为什么人们会建议开源新手从文档开始……因为文档是开源中最难的部分，或者说是开发中最难的部分。”

Sam Boyer: 我承认这从另一个角度说确实有道理，但当你对一个东西了解得足够多时，就会忘记怎么为不了解的人写文档。当你第一次接触某个项目时，你的脑海还是一张白纸，对这个东西的运作方式一无所知。记录下你学习软件时的经验, 这是一个帮助后来者的机会，这种时刻一旦错过就无法重现。

Carlisia Thompson: 是的，说得好。

Erik St. Martin: 我的分享是一个叫 Helm 的项目，这是 Kubernetes 的一部分。他们有一种叫 chart 的东西，基本上是为知名应用程序提供的引导式安装方式。比如说 Redis 或 MySQL 之类的项目，有一套共享的安装和运行方式，可以在 Kubernetes 集群上使用。这是第一个从孵化器中出来并被 Kubernetes 正式接纳的项目之一。

我看到有个地方，好像是 Kubeapps.com……好像有人最近才发布了……

Brian Ketelsen: 是的，KubeApps。

Erik St. Martin: 是的，你应该能够去搜索这些你可能想要安装的常见项目的 Helm chart。他们已经为此努力了很长一段时间。

Brian Ketelsen: Helm 主要由 Open Deis 的团队推动。他们对 Go 社区和 Kubernetes 都做出了很棒的贡献，这很酷。

Sam Boyer: 而且 Helm 最初是由 Matt Butcher 创建的，他也是 Glide 的原始作者。

Brian Ketelsen: 这真是一个完美的闭环。

Sam Boyer: 确实是。

Brian Ketelsen: [唱歌中] 这是一场生命的轮回...

Sam Boyer: 他曾经跟我说过，“我总是在写包管理工具，我也不知道为什么会这样...” [笑声]

Erik St. Martin: 只是不同类型的打包方式罢了。

Sam Boyer: 确实如此。

Brian Ketelsen: 你们想让我继续唱下去结束节目吗？

Erik St. Martin: 不，求你了别唱。

Brian Ketelsen: 好吧，如果想听的话可以告诉我。

Sam Boyer: 我其实还挺享受的，不知道你们怎么想... [笑声]

Brian Ketelsen: 谢谢！Sam，你下次可以再来...

Sam Boyer: 哦，这真好！

Erik St. Martin: 那是不是意味着我不能再来了？

Brian Ketelsen: 是的，下周 Carlisia 会占你的位子。

Carlisia Thompson: 哦，天哪... [笑声]

Brian Ketelsen: 你被开除了！你竟敢在我的电脑上安装 npm？

Erik St. Martin: 好吧，严格来说，你是自己装的...

Brian Ketelsen: 我用了 npm 很多年了，只是从不承认而已。我三年前曾公开发推说“Docker 就像 Node 的安全套”，这是真的。 [笑声]

Carlisia Thompson: 无可奉告。

Erik St. Martin: 好吧，有点尴尬... [笑声] 那么，就此打住吧，谢谢大家参与这次节目。非常感谢你来做客，Sam。和你聊天很愉快。

Sam Boyer: 感谢给我这个机会。

Erik St. Martin: ...尤其是能更深入了解一些细节。

Sam Boyer: 是的，这确实很棒。

Brian Ketelsen: 继续努力！谢谢你所做的一切！

Erik St. Martin: 还有，大家请积极参与，运行 dep 并提交问题反馈。

Sam Boyer: 是的！我们很快就会发布这份路线图，你们的所有贡献都会非常重要且有价值。请大家多多参与！

Erik St. Martin: 如果发现问题，提交 issue，但如果带着 PR 一起提交，那就是额外加分了。

Sam Boyer: 完全正确！

Erik St. Martin: 非常感谢我们的所有听众，包括实时收听的听众以及节目制作完成后收听的观众。当然还要特别感谢我们今天节目的赞助商 Toptal 和 Compose。如果没有他们，我们就无法继续做这个节目。请把节目分享给朋友和其他 Go 程序员。我们的网址是 GoTime.fm，你可以在 Twitter 上找到我们。如果你想上节目，或者对已安排的嘉宾有问题或建议，请访问 ping。就这样吧，大家再见！我们下周见。

Carlisia Thompson: 再见，谢谢你，Sam。

Sam Boyer: 谢谢大家，真的很棒。