Go 包依赖管理工具 —— govendor

govendor 是一个基于 vendor 机制实现的 Go 包依赖管理命令行工具。与原生 vendor 无侵入性融合,也支持从其他依赖管理工具迁移,可以很方便的实现同一个包在不同项目中不同版本、以及无相互侵入的开发和管理。vendor 特性最开始的时候,Go 并没有提供较为妥当的包管理工具。从 1.5 版本开始提供了 vendor 特性,但需要手动设置环境变量 GO15VENDOREXPERIMENT=1。在执行 go build 或 go run 命令时,会按照以下顺序去查找包:当前包下的 vendor 目录向上级目录查找,直到找到 src 下的 vendor 目录在 GOROOT 目录下查找在 GOPATH 下面查找依赖包在发布 1.6 版本时,该环境变量的值已经默认设置为 1 了,该值可以使用 go env 命令查看。在发布 1.7 版本时,已去掉该环境变量,默认开启 vendor 特性。vendor 使用建议一个库工程(不包含 main 的 package)不应该在自己的版本控制中存储外部的包在 vendor 目录中,除非有特殊原因并且知道为什么要这么做。在一个应用中,(包含 main 的 package),建议只有一个 vendor 目录,且在代码库一级目录。govendor 简介govendor 是一个基于 vendor 目录机制的包管理工具。支持从项目源码中分析出依赖的包,并从 $GOPATH 复制到项目的 vendor 目录下支持包的指定版本,并用 vendor/vendor.json 进行包和版本管理,这点与 PHP 的 Composer 类似支持用 govendor add/update 命令从 $GOPATH 中复制依赖包如果忽略了 vendor// 文件,可用 govendor sync 恢复依赖包可直接用 govendor fetch 添加或更新依赖包可用 govendor migrate 从其他 vendor 包管理工具中一键迁移到 govendor支持 Linux,macOS,Windows,甚至现有所有操作系统支持 Git、Hg、SVN,BZR(必须指定一个路径)govendor 使用要求:项目必须在 $GOPATH/src 目录下如果 Go 版本为 1.5,则必须手动设置环境变量 set GO15VENDOREXPERIMENT=1安装go get -u github.com/kardianos/govendor为了方便快捷使用 govendor,建议将 $GOPATH/bin 添加到 PATH 中。Linux/macOS 如下设置:export PATH="$GOPATH/bin:$PATH"初始化在项目根目录下执行以下命令进行 vendor 初始化:govendor init项目根目录下即会自动生成 vendor 目录和 vendor.json 文件。此时 vendor.json 文件内容为:{ “comment”: “”, “ignore”: “test”, “package”: [], “rootPath”: “govendor-example”}常用命令将已被引用且在 $GOPATH 下的所有包复制到 vendor 目录govendor add +external仅从 $GOPATH 中复制指定包govendor add gopkg.in/yaml.v2列出代码中所有被引用到的包及其状态govendor list e github.com/gin-contrib/sse e github.com/gin-gonic/gin e github.com/gin-gonic/gin/binding e github.com/gin-gonic/gin/internal/json e github.com/gin-gonic/gin/render e github.com/golang/protobuf/proto e github.com/mattn/go-isatty e github.com/ugorji/go/codec e gopkg.in/go-playground/validator.v8 e gopkg.in/yaml.v2pl govendor-example m github.com/json-iterator/go m golang.org/x/sys/unix列出一个包被哪些包引用govendor list -v fmt s fmt ├── e github.com/gin-contrib/sse ├── e github.com/gin-gonic/gin ├── e github.com/gin-gonic/gin/render ├── e github.com/golang/protobuf/proto ├── e github.com/ugorji/go/codec ├── e gopkg.in/go-playground/validator.v8 ├── e gopkg.in/yaml.v2 └── pl govendor-example从远程仓库添加或更新某个包(不会在 $GOPATH 也存一份)govendor fetch golang.org/x/net/context安装指定版本的包govendor fetch golang.org/x/net/context@a4bbce9fcae005b22ae5443f6af064d80a6f5a55govendor fetch golang.org/x/net/context@v1 # Get latest v1..* tag or branch.govendor fetch golang.org/x/net/context@=v1 # Get the tag or branch named “v1”.只格式化项目自身代码(vendor 目录下的不变动)govendor fmt +local只构建编译项目内部的包govendor install +local只测试项目内部的测试案例govendor test +local构建所有 vendor 包govendor install +vendor,^program拉取所有依赖的包到 vendor 目录(包括 $GOPATH 存在或不存在的包)govendor fetch +out包已在 vendor 目录,但想从 $GOPATH 更新govendor update +vendor已修改了 $GOPATH 里的某个包,现在想将已修改且未提交的包更新到 vendorgovendor update -uncommitted <updated-package-import-path>Fork 了某个包,但尚未合并,该如何引用到最新的代码包govendor fetch github.com/normal/pkg::github.com/myfork/pkg此时将从 myfork 拉取代码,而不是 normal。vendor.json 中记录了依赖包信息,该如何拉取更新govendor syncgovendor 子命令各子命令详细用法可通过 govendor COMMAND -h 或阅读 github.com/kardianos/govendor/context 查看源码包如何实现的。子命令功能init创建 vendor 目录和 vendor.json 文件list列出&过滤依赖包及其状态add从 $GOPATH 复制包到项目 vendor 目录update从 $GOPATH 更新依赖包到项目 vendor 目录remove从 vendor 目录移除依赖的包status列出所有缺失、过期和修改过的包fetch从远程仓库添加或更新包到项目 vendor 目录(不会存储到 $GOPATH)sync根据 vendor.json 拉取相匹配的包到 vendor 目录migrate从其他基于 vendor 实现的包管理工具中一键迁移get与 go get 类似,将包下载到 $GOPATH,再将依赖包复制到 vendor 目录license列出所有依赖包的 LICENSEshell可一次性运行多个 govendor 命令govendor 状态参数状态缩写含义+locall本地包,即项目内部编写的包+externale外部包,即在 GOPATH 中、却不在项目 vendor 目录+vendorv已在 vendor 目录下的包+stds标准库里的包+excludedx明确被排除的外部包+unusedu未使用的包,即在 vendor 目录下,但项目中并未引用到+missingm被引用了但却找不到的包+programp主程序包,即可被编译为执行文件的包+outside 相当于状态为 +external +missing+all 所有包支持状态参数的子命令有:list、add、update、remove、fetchGo modules普大喜奔的是,从 Go 1.11 版本开始,官方已内置了更为强大的 Go modules 来一统多年来 Go 包依赖管理混乱的局面(Go 官方之前推出的 dep 工具也几乎胎死腹中),并且将在 1.12 版本中正式默认开启。目前已受到社区的看好和强烈推荐,建议新项目采用 Go modules。参考govendor 项目golang使用vendor目录来管理依赖包Golang包管理工具之govendor的使用感谢您的阅读,觉得内容不错,点个赞吧 ????原文地址: https://shockerli.net/post/go… ...

March 25, 2019 · 2 min · jiezi

使用 govendor 管理你的 go 项目包版本

govendor 是 go 的一个比较好用包版本管理工具。主要用来保证 go 项目在协同开发或发版部署时,保证部署安装的依赖包版本对当前项目是稳定可用的。为什么要使用包版本管理工具java 的 maven,php 的 composer,nodejs 的 npm,python 的 requirement.txt,golang 的 govendor。例1:你的项目依赖一个github.com/foo 1.0.0的包,如果不使用包版本管理工具,他人在本地部署安装你的项目时,安装的包版本可能是最新的github.com/foo 2.0.0,如果两个版本存在兼容问题,就会出现crashed。例2:使用 go get 安装的项目依赖包的存放位置为 $GOPATH/src,即与你的项目路径同级,我们使用 git 时就没办法管理这些依赖包,不能也不应该将它们也提交到git仓库,如果提供一个包版本说明说,将说明书提交仓库,他人则根据此说明书安装依赖包。为解决此问题,govendor出现了,govendor会将项目依赖的包版本记录到your_proj/vendor/vendor.json中,后期将此文件提交至 git 仓库,则其他人 pull or clone 你的项目到本地后,即可使用 govendor 安装稳定的包依赖。govendor 工作流首先要部署好你的 go 环境,并将 $GOPATH/bin 路径加载到系统PATH中。我们将体验一遍如何使用govendor管理你的项目包版本,及如何安装他人的govendor管理的go项目(这点才是精华,很多博文都不提及,为什么版本管理,不就是为了能让程序在其他地方也能稳定运行嘛)。安装govendorgo get -u -v github.com/kardianos/govendor#运行 govendor 检测安装结果govendor如果能看到帮助提示信息,说明安装ok。项目初始化使用 govendor 初始化你的项目,将会在工程目录下自动创建 vendor 目录及 vendor/vendor.json 文件。如果是已有项目,也没关系,govendor允许你在项目开发的任何阶段去使用它,它总能将你的项目包版本管理起来。mkdir go_proj && cd go_proj# init projgovendor init#查看目录结构tree.└── vendor └── vendor.json1 directory, 1 file安装&管理包govendor get我们仍然可以通过 go get安装包到 $GOPATH/src下,但使用govendor get可以在安装包的同时将包纳入版本管理,而且会将包安装在$GOPATH/src/your_proj/vendor,更符合我们的要求。#安装在 $GOPATH/src 下go get github.com/go-sql-driver/mysql#安装在$GOPATH/src/your_proj/vendor下govendor get github.com/go-sql-driver/mysqlgovendor list & govendor addgovendor list可以帮助我们查看项目中引入的包的状态,即哪些是没有纳入版本管理的外部包,哪些是纳入版本管理的包,哪些是标准包,哪些是本地包等。govendor listStatus Types +local (l) packages in your project 你自己在项目中定义的包 +external (e) referenced packages in GOPATH but not in current project 使用 go get 安装的项目外部包 +vendor (v) packages in the vendor folder 使用 govendor get 安装的纳入版本管理的包 +std (s) packages in the standard library 标准包 fmt/time/runtime 等 +excluded (x) external packages explicitly excluded from vendoring 排除的外部包 +unused (u) packages in the vendor folder, but unused 安装但没引用的包 +missing (m) referenced packages but not found 引用但没安装的包 缺失了 +program (p) package is a main package 你的项目主包,它总会同 l 一起出现 pl 这个很好理解吧 +outside +external +missing +all +all packagesgovendor add则是方便我们在任何时间将项目包纳入版本管理。比如我们前期一直使用或现在偶然使用go get安装了一个项目的依赖包,此包是不会被记录在vendor/vendor.json中的,即没有纳入版本管理,那该如何将其纳入呢?go add +external执行上方命令即可,这样项目依赖的包都纳入了版本管理。提交git仓库在提交源码至git仓库时,我们没有必要将依赖包源文件也一并提交至仓库,所以 .gitignore 的编排要加上如下规则:# vi .gitignorevendor/*!vendor/vendor.json即排除vendor下的除vendor/vendor.json外的所有文件(这些文件其实就是依赖包),将vendor/vendor.json提交至git仓库即可。安装/部署 govendor 项目当我们从git仓库下载好govendor管理的golang项目时,需要安装好项目的包依赖,才可以正常的运行程序,类似 composer install的作用,这里则是使用govendor sync。这里使用我的一个 govendor 管理的基于Gin的MVC简易框架给大家演示一下:cd $GOPATH/src && git clone git@github.com:sqrtcat/easy-gin.git && cd easy-gingovendor sync运行程序即可,简单! ...

March 16, 2019 · 1 min · jiezi

Android VNDK限制下的解决方案

你有没有遇到过这个错误呢?F linker: CANNOT LINK EXECUTABLE “/system/bin/xxx”: library “libxxx.so” not found首先在android生态里,一般的应用开发者,不会遇到这个问题。系统开发者也只有在某些情况下会遇到这个问题。什么情况呢?我们先来了解下什么是vndk以及其规则。VNDK就是vendor NDKSDK(software development kit),NDK(native development kit)都不陌生吧,尤其是android应用开发者来说,就是某某开发包包含了api及其规范等等使得你开发的apk可以在android上运行。那么怎么理解,vendor native development kit呢,这要从android整个软硬件框架及其生态说起,开发者常说的android其实指的是AOSP,而一个完整的android生态,至少包含四个个部分,一个是android,一个是硬件厂家芯片,屏幕,整机等等,一个是应用开发者,一个是消费者(是硬件消费者同时也是软件,内容消费者)。可以看到android在产品架构上起了一个承上启下的作用,将硬件厂家和开发者连接在一起。这里有一个看似矛盾的地方,android是谷歌开源的,而谷歌是一个商业公司不是慈善机构。谷歌开源的目的是推广它的广告系统从中得利,但是太开放版本混乱体验不一致反过来会损害它的利益。所以需要在开放的同时进行控制。如果SDK,NDK是应用开发者的开发规范,那VNDK是针对硬件厂家的开发规范。谷歌是这样介绍VNDK的在理想的 Android 8.0 及更高版本环境中,框架进程不加载供应商共享库,所有供应商进程仅加载供应商共享库(和一部分框架共享库),而框架进程与供应商进程之间的通信由 HIDL 和硬件 binder 控制。主要意思是,系统分区和vendor分区隔离,尤其系统分区内的框架进程不要链接加载vendor下的so库,规则不允许这样做,强行加载会报错,就是文章开头贴的错误。谷歌以这种方式保持系统对底层的统一,限制每个硬件厂家在底层对系统的不统一的修改。所以系统开发者如果用框架进程无论是已经存在的还是新增的去加载vendor下的库都会遇到这个问题。可能有人会说,android是开源的,我把这个限制在源码里去掉就可以了啊,别忘了我们在之前一篇文章里说过谷歌会考试,这么做考试会不及格的。不及格就拿不到谷歌的印章,没有印章,产品想上市麻烦事有很多,所以这几行代码代价太高了,不能这么做。如何满足VNDK的规则呢?VNDK给出了解决方案方案1.把vendor下的资源通过供应商进程的方式暴露出来,框架进程通过hidl或者硬件binder的方式与供应商进程通信达到访问vendor资源的目的。方案2.如果vendor下的资源比如so库,能够从vendor下彻底脱离,也可以拷贝一份到system下,这样合理的避开了这个问题,而且还省掉了开发供应商进程的成本,以及hidl或binder通信的消耗。在框架进程必须要加载这个库的情况下,如果vendor下的so库能彻底脱离vendor,拷贝一份在system是最佳的方案。为什么不是直接挪到system下,而是要拷贝一份呢?因为so放在vendor下就是因为vendor要用,而vendor进程只能加载一部分谷歌允许的框架so,所以这个库如果不是谷歌允许的so只放在system下那vendor也加载不到了。这种情况两边都要放。前几天也遇到了类似的问题用框架进程去加载一个vendor下的共享库,vendor/lib/libxxx.so, vendor/lib64/libxxx.so,这个库是芯片厂家提供的。报告错误,F linker: CANNOT LINK EXECUTABLE “/system/bin/xxx”: library “libxxx.so” not found。正准备将vendor下的libxxx.so拷贝到system下,修改脚本的时候注意到一个叫libxxx_system.so被拷贝到了system下,libxxx_system.so与libxxx.so同名,只是多了_system后缀。突然一个想法闪过“libxxx_system.so就是libxxx.so在system的拷贝”,初步通过3个步骤得到了确认1.看大小两个差不多2.看链接的库,两个so链接的库一样,而且都是谷歌允许的框架的so3.看符号表基本一样然后框架进程改成链接system/lib/libxxx_system.so和system/lib64/libxxx_system.so编译通过,运行通过,问题解决。看来芯片厂家已经做了相关的预案。仅献给遇到此问题的朋友,F linker: CANNOT LINK EXECUTABLE “/system/bin/xxx”: library “libxxx.so” not found。VNDK详细介绍:https://source.android.com/de…

January 24, 2019 · 1 min · jiezi