golangvendor

发布网友 发布时间：2024-09-17 08:35

我来回答

共1个回答

热心网友 时间：2024-09-28 05:48

golang的GOPATH和vendor的搜索关系

项目只有一个包，即main包，没有引用其他的包(golang自带的系统包除外)。

然后设置GOPATH=path/to/goproject，再运行gobuildmyproject，这样就可以在任何目录下面编译，编译生成的可执行文件就在编译所在的目录下，而不是包源文件所在的目录。

基本规则：

鉴于此，建议golang项目必须严格按照规范的目录结构组织，哪怕是前面这种自包含的项目。

基本规则：

如果一个包在vendor和GOPATH下面都存在那么谁会优先使用呢。

结论是：

包mydeps在vendor目录下面和GOPATH路径下面都存在了，那么main.go引用的时候只会引用vendor下面的mydeps(src/myproject/vendor/mydeps)，而忽略GOPATH下面的mydeps包(src/mydeps)。

前面提到GOPATH和PATH类似，可以包含多个路径，中间用分号隔开，go在搜索包的时候会按手续从前往后搜搜。那么vendor怎么处理层级关系呢。

规则是：

举例：

如果src/mydep/mydep1/mydep.go引用了myvendor1和myvendor，那是怎么搜索的呢

我喜欢jetbrains系列的IDE+go插件。不过我要说的是这个问题主要看你的观点如何。

说eclipse：

构建方式是使用goinstall命令，每一次编译运行都是goinstall。这样的好处就是如果你有很多的包，下载下来并没有编译，这样每次编译速度是很快的。而且（！）goinstall符合go官方的项目结构，官方说过了，一个go的项目应该是以个gopath，包含src，pkg，bin三个主要目录。所以说goinstall个人认为才是主要的go编译方式。

说eclipse的缺点：

其实eclipse插件的go编译方式，还有目录结构，项目结构，都是非常完美的！！！！真的很完美！可是，他的代码提示，太差件！大括号都不能自动补全，gdb32bit64bit兼容问题，eclipseC++没有htmljs插件，需要手动安装，几乎不能开箱即用。不过如果你是开发算法，数据处理，还是推荐eclipse的，毕竟其他都无关紧要。

说jetbrains：

说先说clione肯定不适合，新建项目没有向导，导致改成go项目各种不开心，比如图标对于我来说就无法接受golib不是小耗子~这是次要的，重要的是各个文件都是灰色的（没有在cmake中包含的结果），然后说剩下的，phpstorm这个不说了，估计很少有人插件按在这里，webstorm，体验也不是很好，idea？体验很好，可是毕竟比较重，尤其是现在加入了自家的K啥玩意（无意冒犯，没记住单词）~可是话说回来，go跟C系列IDE配合才是最佳，跟java系列一点不搭关系，用idea似乎有点格格不入，但是！idea支持新建项目向导，lib的图标也很清晰，最后还是选择idea吧，期待clion的强大起来！

再说jetbrains系列缺点：

插件的构建方式是gobuiild这个让人很不爽，我们几乎不确定会构建到什么地方去，还要每次设置一下run配置。这个可能无关紧要，毕竟不是什么大的毛病，可是gobuild不能缓存.a文件，直接构建的结果就是很多第三方包的情况下很慢！所以建议安装包的时候手动install一下解决这个问题。自带代码格式化，这个格式化跟go格格不入，总的来说就是蛋疼，心碎，菊花痒。

最后说liteIDE：

轻量级IDE，我可以说是国人GO伟大作品典范，然而默认构建也是gobuild，项目管理方式不符合go官方标准。代码提示不能自动导入（eclipse也不能），不过如果你的项目是以包为单位的，那么另当别论。一定很不错，毕竟是轻量级专门针对GO的IDE！

说这些，其实还有很大一部分取决于你的项目是用vendor机制管理，还是godeps机制管理依赖关系。go不像java拥有强大的几乎天下一统的maven（无意冒犯，暂不评价其他构建套件）。

go没有官方包仓库。

go没有官方包管理工具。

go没有官方自动化构建套件。

上面三个没有是致命要害。导致民间各种百花齐放。

说说我的项目怎么管理

gpm一个shell工具（windows下你可以用git的bash，或者cygwin~）

我是严格艳照官方推荐方式管理go项目，一个go项目一个gopath。系统的gopath只是为了安装go命令，我没有配置gobin，意义不大。

项目的依赖跟我的代码包都在src下（非vendor）

vendor用来存放包的特殊依赖，发布项目直接把依赖包发布上去（公网管理则只上传依赖关系文件godeps文件）

资源文件等都放在src目录同级，编译文件放在bin，引用直接../引用。

使用go很长时间后才整明白vendor的用法为啥这么坑人。

注意

这和当前工作路径相关：

gomodule和vendor是两个冲突的设计，二者只能选一，不可混用。

如果从vendor到module迁移的怎么办：

-mod=vendor

gomod使用

目前，golang的包管理工具有很多，用的比较多的包括：govendor、godep、glide等等。但是，一直以来，golang官方都没有提供一个标准的包管理工具，知道go1.11发布后，出现了一个实验中的gomodule。

a、全局启用

b、当前shell窗口启用

c、常用代理地址

3.1初始化

4.1查看所有依赖包

4.2查看包有哪些版本

4.3如何更换版本

4.4使用gomodedit直接修改

4.5删除未使用的依赖项

4.6查看所有命令

Go1.11版本支持临时环境变量GO111MODULE，通过该环境变量来控制依赖包的管理方式。当GO111MODULE的值为on时，那么就会使用modules功能，这种模式下，

当GO111MODULE的值为off时，不再使用modules功能。此时软件包的使用顺序为：

优先使用vendor目录下面的包，如果vendor下面没有搜索到，再搜索

要么完整使用vendor下面的包，要么完整使用$GOPATH下面的包，不会混合使用。

当使用gomodvendor指令，将依赖包全部拷贝至当前项目下后，当前项目就可以随意拷贝分发，避免因网络问题造成接收者安装依赖包的麻烦。

事情是这样的，因为小马本次要写一个go项目。但是因为一些权限问题，一些依赖包在内网小马获取不到，于是只能求助大大。大大给的策略就是他先把所有的依赖包gomod,然后gomodvendor迁移到项目目录vendor下进行本地依赖载入即可，也就是使用gobuild-mod=vendor来编译即可。一切似乎看起来还是那么完美。然后正要起飞，直接翻车，现场如下。【这里插播一条发现，就是使用golangIDEgobuild和使用命令行gobuild的区别在于前者不会生成.exe文件】

将大大gomodvendor完的包pull到本地，只要编译就会发生如下错误（以下省略了一部分类似的报错）。其实是go.mod内的所有依赖包都报错。

大大说他的本地编译是正常的。不得不怀疑是不是因为大大本地gopath还有一份包依赖的原因，然而经查并不是这个问题。翻阅了网络上的大部分资料无果，网络上要么是说是因为识别不到包，按照提示重新go?mod?vendor一下就可以了。小马蛮试了一下，不出所料必然地报远程报获取不到呢，IDE的报错定位其实是不准确的。再次检查vendor/modules.txt文件，没有问题，无果。于是开始质疑golangIDE的版本支持问题，无果。看了下go.mod文件中写着go1.14，也没错呢，小马用的GOSDK正是1.14.4版本。敲出goenv查看环境配置，GO111MODULE=on，因为环境变量是auto,但是go到一定版本后默认是on，也没问题，无果。那问题出在哪呢？由于没有依赖包拉取权限，只能再次求助大大，大大表示也很奇怪，一番折腾，于是问题得到解决。【这里插播一条好玩的东西，就是GO111MODULE为什么是GO111呢，因为其实1.11版本开始支持MODULE的】

结论是：因为大大go?mod的时候用的是go1.13，而我编译的时候用的1.14，所以就报了这个奇怪的错误。youwhat?直接懵逼。但是为啥go.mod文件中写的版本要求是1.14，而大大用1.13也编译得好好的。

这是个大坑，掉进坑里自己扑腾了一天！！希望大家谨慎入坑。

爬坑一小时出坑一秒钟，每一次的爬坑都是充满着十八般绝技。奇怪的姿势又增加了。

go运行方式有哪几种？

如果GO111MODULE是auto则根据项目目录位置和是否含有go.mod文件来决定使用什么模式。如果是GO111MODULE=off则使用gopath，如果是on则使用module模式。gopath模式下的src目录下不能有go.mod文件，否则报错。

一些gomod命令记录备用，国内的资料并不多（注意gomod?命令在?$GOPATH?里默认是执行不了的，因为?GO111MODULE?的默认值是?auto。默认在$GOPATH?里是不会执行，如果一定要强制执行，就设置环境变量为?on。）：

go/src/go-cve-dictionary-master

#mvsubcommands-master/opt/go/src/subcommands

#mvnet-master/opt/go/src/net

#mvgo-sqlite3-master/opt/go/src/go-sqlite3

都放到了go/src目录下了，我还修改了go-cve-dictionary-master/main.go文件内容，如下所示：

import(

"flag"

"fmt"

"os"

"golang.org/x/net/context"改为“context”

"github.com/google/subcommands"改为subcommands

"github.com/kotakanbe/go-cve-dictionary/commands"改为go-cve-dictionary/commands

"github.com/kotakanbe/go-cve-dictionary/version"改为go-cve-dictionary/version

_"github.com/mattn/go-sqlite3"改为go-sqlite3

)

执行#goinstallgo-cve-dictionary-master错误如下：

can'tloadpackage:/opt/go/src/go-cve-dictionary-master/main.go:14:2:non-standardimport"github.com/mattn/go-sqlite3"instandardpackage"go-cve-dictionary-master"

go-cve-dictionary-master/main.go:11:2:cannotfindpackage"go-cve-dictionary/commands"inanyof:

/opt/go/src/vendor/go-cve-dictionary/commands(vendortree)

/opt/go/src/go-cve-dictionary/commands(from$GOROOT)

/root/go/src/go-cve-dictionary/commands(from$GOPATH)

go-cve-dictionary-master/main.go:12:2:cannotfindpackage"go-cve-dictionary/version"inanyof:

/opt/go/src/vendor/go-cve-dictionary/version(vendortree)

/opt/go/src/go-cve-dictionary/version(from$GOROOT)

/root/go/src/go-cve-dictionary/version(from$GOPATH)

subcommands/subcommands.go:29:2:cannotfindpackage"golang.org/x/net/context"inanyof:

/opt/go/src/vendor/golang.org/x/net/context(vendortree)

/opt/go/src/golang.org/x/net/context(from$GOROOT)

/root/go/src/golang.org/x/net/context(from$GOPATH

热心网友 时间：2024-09-28 05:40

golang的GOPATH和vendor的搜索关系

项目只有一个包，即main包，没有引用其他的包(golang自带的系统包除外)。

然后设置GOPATH=path/to/goproject，再运行gobuildmyproject，这样就可以在任何目录下面编译，编译生成的可执行文件就在编译所在的目录下，而不是包源文件所在的目录。

基本规则：

鉴于此，建议golang项目必须严格按照规范的目录结构组织，哪怕是前面这种自包含的项目。

基本规则：

如果一个包在vendor和GOPATH下面都存在那么谁会优先使用呢。

结论是：

包mydeps在vendor目录下面和GOPATH路径下面都存在了，那么main.go引用的时候只会引用vendor下面的mydeps(src/myproject/vendor/mydeps)，而忽略GOPATH下面的mydeps包(src/mydeps)。

前面提到GOPATH和PATH类似，可以包含多个路径，中间用分号隔开，go在搜索包的时候会按手续从前往后搜搜。那么vendor怎么处理层级关系呢。

规则是：

举例：

如果src/mydep/mydep1/mydep.go引用了myvendor1和myvendor，那是怎么搜索的呢

我喜欢jetbrains系列的IDE+go插件。不过我要说的是这个问题主要看你的观点如何。

说eclipse：

构建方式是使用goinstall命令，每一次编译运行都是goinstall。这样的好处就是如果你有很多的包，下载下来并没有编译，这样每次编译速度是很快的。而且（！）goinstall符合go官方的项目结构，官方说过了，一个go的项目应该是以个gopath，包含src，pkg，bin三个主要目录。所以说goinstall个人认为才是主要的go编译方式。

说eclipse的缺点：

其实eclipse插件的go编译方式，还有目录结构，项目结构，都是非常完美的！！！！真的很完美！可是，他的代码提示，太差件！大括号都不能自动补全，gdb32bit64bit兼容问题，eclipseC++没有htmljs插件，需要手动安装，几乎不能开箱即用。不过如果你是开发算法，数据处理，还是推荐eclipse的，毕竟其他都无关紧要。

说jetbrains：

说先说clione肯定不适合，新建项目没有向导，导致改成go项目各种不开心，比如图标对于我来说就无法接受golib不是小耗子~这是次要的，重要的是各个文件都是灰色的（没有在cmake中包含的结果），然后说剩下的，phpstorm这个不说了，估计很少有人插件按在这里，webstorm，体验也不是很好，idea？体验很好，可是毕竟比较重，尤其是现在加入了自家的K啥玩意（无意冒犯，没记住单词）~可是话说回来，go跟C系列IDE配合才是最佳，跟java系列一点不搭关系，用idea似乎有点格格不入，但是！idea支持新建项目向导，lib的图标也很清晰，最后还是选择idea吧，期待clion的强大起来！

再说jetbrains系列缺点：

插件的构建方式是gobuiild这个让人很不爽，我们几乎不确定会构建到什么地方去，还要每次设置一下run配置。这个可能无关紧要，毕竟不是什么大的毛病，可是gobuild不能缓存.a文件，直接构建的结果就是很多第三方包的情况下很慢！所以建议安装包的时候手动install一下解决这个问题。自带代码格式化，这个格式化跟go格格不入，总的来说就是蛋疼，心碎，菊花痒。

最后说liteIDE：

轻量级IDE，我可以说是国人GO伟大作品典范，然而默认构建也是gobuild，项目管理方式不符合go官方标准。代码提示不能自动导入（eclipse也不能），不过如果你的项目是以包为单位的，那么另当别论。一定很不错，毕竟是轻量级专门针对GO的IDE！

说这些，其实还有很大一部分取决于你的项目是用vendor机制管理，还是godeps机制管理依赖关系。go不像java拥有强大的几乎天下一统的maven（无意冒犯，暂不评价其他构建套件）。

go没有官方包仓库。

go没有官方包管理工具。

go没有官方自动化构建套件。

上面三个没有是致命要害。导致民间各种百花齐放。

说说我的项目怎么管理

gpm一个shell工具（windows下你可以用git的bash，或者cygwin~）

我是严格艳照官方推荐方式管理go项目，一个go项目一个gopath。系统的gopath只是为了安装go命令，我没有配置gobin，意义不大。

项目的依赖跟我的代码包都在src下（非vendor）

vendor用来存放包的特殊依赖，发布项目直接把依赖包发布上去（公网管理则只上传依赖关系文件godeps文件）

资源文件等都放在src目录同级，编译文件放在bin，引用直接../引用。

使用go很长时间后才整明白vendor的用法为啥这么坑人。

注意

这和当前工作路径相关：

gomodule和vendor是两个冲突的设计，二者只能选一，不可混用。

如果从vendor到module迁移的怎么办：

-mod=vendor

gomod使用

目前，golang的包管理工具有很多，用的比较多的包括：govendor、godep、glide等等。但是，一直以来，golang官方都没有提供一个标准的包管理工具，知道go1.11发布后，出现了一个实验中的gomodule。

a、全局启用

b、当前shell窗口启用

c、常用代理地址

3.1初始化

4.1查看所有依赖包

4.2查看包有哪些版本

4.3如何更换版本

4.4使用gomodedit直接修改

4.5删除未使用的依赖项

4.6查看所有命令

Go1.11版本支持临时环境变量GO111MODULE，通过该环境变量来控制依赖包的管理方式。当GO111MODULE的值为on时，那么就会使用modules功能，这种模式下，

当GO111MODULE的值为off时，不再使用modules功能。此时软件包的使用顺序为：

优先使用vendor目录下面的包，如果vendor下面没有搜索到，再搜索

要么完整使用vendor下面的包，要么完整使用$GOPATH下面的包，不会混合使用。

当使用gomodvendor指令，将依赖包全部拷贝至当前项目下后，当前项目就可以随意拷贝分发，避免因网络问题造成接收者安装依赖包的麻烦。

事情是这样的，因为小马本次要写一个go项目。但是因为一些权限问题，一些依赖包在内网小马获取不到，于是只能求助大大。大大给的策略就是他先把所有的依赖包gomod,然后gomodvendor迁移到项目目录vendor下进行本地依赖载入即可，也就是使用gobuild-mod=vendor来编译即可。一切似乎看起来还是那么完美。然后正要起飞，直接翻车，现场如下。【这里插播一条发现，就是使用golangIDEgobuild和使用命令行gobuild的区别在于前者不会生成.exe文件】

将大大gomodvendor完的包pull到本地，只要编译就会发生如下错误（以下省略了一部分类似的报错）。其实是go.mod内的所有依赖包都报错。

大大说他的本地编译是正常的。不得不怀疑是不是因为大大本地gopath还有一份包依赖的原因，然而经查并不是这个问题。翻阅了网络上的大部分资料无果，网络上要么是说是因为识别不到包，按照提示重新go?mod?vendor一下就可以了。小马蛮试了一下，不出所料必然地报远程报获取不到呢，IDE的报错定位其实是不准确的。再次检查vendor/modules.txt文件，没有问题，无果。于是开始质疑golangIDE的版本支持问题，无果。看了下go.mod文件中写着go1.14，也没错呢，小马用的GOSDK正是1.14.4版本。敲出goenv查看环境配置，GO111MODULE=on，因为环境变量是auto,但是go到一定版本后默认是on，也没问题，无果。那问题出在哪呢？由于没有依赖包拉取权限，只能再次求助大大，大大表示也很奇怪，一番折腾，于是问题得到解决。【这里插播一条好玩的东西，就是GO111MODULE为什么是GO111呢，因为其实1.11版本开始支持MODULE的】

结论是：因为大大go?mod的时候用的是go1.13，而我编译的时候用的1.14，所以就报了这个奇怪的错误。youwhat?直接懵逼。但是为啥go.mod文件中写的版本要求是1.14，而大大用1.13也编译得好好的。

这是个大坑，掉进坑里自己扑腾了一天！！希望大家谨慎入坑。

爬坑一小时出坑一秒钟，每一次的爬坑都是充满着十八般绝技。奇怪的姿势又增加了。

go运行方式有哪几种？

如果GO111MODULE是auto则根据项目目录位置和是否含有go.mod文件来决定使用什么模式。如果是GO111MODULE=off则使用gopath，如果是on则使用module模式。gopath模式下的src目录下不能有go.mod文件，否则报错。

一些gomod命令记录备用，国内的资料并不多（注意gomod?命令在?$GOPATH?里默认是执行不了的，因为?GO111MODULE?的默认值是?auto。默认在$GOPATH?里是不会执行，如果一定要强制执行，就设置环境变量为?on。）：

go/src/go-cve-dictionary-master

#mvsubcommands-master/opt/go/src/subcommands

#mvnet-master/opt/go/src/net

#mvgo-sqlite3-master/opt/go/src/go-sqlite3

都放到了go/src目录下了，我还修改了go-cve-dictionary-master/main.go文件内容，如下所示：

import(

"flag"

"fmt"

"os"

"golang.org/x/net/context"改为“context”

"github.com/google/subcommands"改为subcommands

"github.com/kotakanbe/go-cve-dictionary/commands"改为go-cve-dictionary/commands

"github.com/kotakanbe/go-cve-dictionary/version"改为go-cve-dictionary/version

_"github.com/mattn/go-sqlite3"改为go-sqlite3

)

执行#goinstallgo-cve-dictionary-master错误如下：

can'tloadpackage:/opt/go/src/go-cve-dictionary-master/main.go:14:2:non-standardimport"github.com/mattn/go-sqlite3"instandardpackage"go-cve-dictionary-master"

go-cve-dictionary-master/main.go:11:2:cannotfindpackage"go-cve-dictionary/commands"inanyof:

/opt/go/src/vendor/go-cve-dictionary/commands(vendortree)

/opt/go/src/go-cve-dictionary/commands(from$GOROOT)

/root/go/src/go-cve-dictionary/commands(from$GOPATH)

go-cve-dictionary-master/main.go:12:2:cannotfindpackage"go-cve-dictionary/version"inanyof:

/opt/go/src/vendor/go-cve-dictionary/version(vendortree)

/opt/go/src/go-cve-dictionary/version(from$GOROOT)

/root/go/src/go-cve-dictionary/version(from$GOPATH)

subcommands/subcommands.go:29:2:cannotfindpackage"golang.org/x/net/context"inanyof:

/opt/go/src/vendor/golang.org/x/net/context(vendortree)

/opt/go/src/golang.org/x/net/context(from$GOROOT)

/root/go/src/golang.org/x/net/context(from$GOPATH