Dep包管理的主要机制

状态和流动

Dep主要围绕“四状态系统”这一模型（一种分类和组织磁盘状态的模型），与包管理器进行交互。尽管这四个状态模型中许多原则都是从现有的包管理器中派生出来的，但还是首先来阐述下这一模型。
简单的说，四状态是：

1. 当前工程的源代码
2. 描述当前项目需要依赖的文件，在dep中，是Gopkg.toml文件。
3. 一个包含可重复描述的完整依赖关系图，在dep中，是Gopkg.lock文件。
4. 依赖包源代码，在dep的当前设计中，是vendor目录

如下图所示：

函数式流动

把dep看作一个系统，那么这些系统会对这些状态之间的关系施加一个单向的函数流。这些函数将上述四个状态视为输入和输出，并将它们从左向右移动。具体来说，有两个函数：

• solving功能，它将当前项目中的导入包和Gopkg.toml中的规则作为输入，不可变的依赖关系图作为传递完成后的输出，形成Gopkg.lock。
• vendor功能，将Gopkg.lock中的信息作为输入，确保项目编译时能使用在Gopkg.lock文件中锁定的版本。

具体如下图所示：

dep命令详解

dep ensure，这是很典型的流动，当Gopkg.toml文件存在时使用，当你的项目中还没有Gopkg.toml文件时，dep init可以帮你生成一个。它们之间的区别在于：dep init不是从现有的Gopkg.toml文件读取数据，而是从用户的GOPATH中构建出一个数据，或者从另一个工具中获取元数据文件。也就是说，dep init自动将项目从其他途径迁移到当前组织的依赖关系。

命令参数

1. -no-vendor标识会导致只生成一个新的Gopkg.lock文件，而没有形成vendor目录
2. -vendor-only标识会跳过生成新的Gopkg.lock文件，导致vendor目录中的包是从已存在的Gopkg.lock中进行读取引入。

如下图所示：

3. -add标识是为了简化新的依赖包的引入，然而-update在管理项目包时仅限于原路径（例如：github.com/foo/bar），-add参数可以将任何包导入路径作为参数（例如：github.com/foo/bar或者github.com/foo/bar/baz）。dep ensure -add命令至少会运行下面动作中的一种：

• 执行solving功能，为新的依赖包生成一个新的Gopkg.lock文件。
• 将版本限制信息写入到Gopkg.toml文件。