前言
以前我都是用的 go get,把依赖包下载到本地,诸如 golang.org/x/* 这一类的都是从 github 上拉取源码,解压到对应路径,但是今天从 github 上拉了个开源项目,按照他的步骤,居然报错了,我本地明明又 golang.org/x/image ,但是他还是从远程仓库拉取,我就去看了下,发现他用了 1.11 版本后引入的 module 的东西,所以就有了这篇文章。
go module 简介
以前我们基本都是 go get 下来对应依赖包,所有的程序都用这些,但是说不定有的程序对依赖包的版本有要求,这就很烦了,go 的包管理也是一直为人诟病,所以就有了现在的 module 这个东西,从 1.11 版本引入。而且采用这种模式之后,go 的项目不必都得建在 gopath 之下了,随便挑个地方就行。
踩坑实记
这一部分就是希望如果有人碰到了跟我一样的坑,别摔的太狠。
起因
早上如常在逛 github,看了下日排行,有个名叫 gameboy 小游戏的项目,感觉比较有意思,就打算把源码弄下来,编译下,本地跑一下,按照教程,go build
入坑
照着以前的思路,我都是 go get ./...把对应的依赖先下一遍,然后运行,但是这个 readme 写的,直接让 go build,相信作者,直接 build,发现自己去下依赖了,我心想,作者可以啊,还自己写个依赖处理插件(后来发现用的 module)?,但是过了会儿,发现他去下 golang.org/x/image 了,我电脑上明明有这个,为啥又去下载了,报错如下
坑一:module 开关
发现上面问题,我就百度去了,看到有说用 replace,我就看了下,然后就发现了 module 这个东西,然后又去百度这个东西,然后试了一个命令发现包了个错
$ go get golang.org/x/net@master
go: cannot use path@version syntax in GOPATH mode
后来发现需要开启 GO111MODULE,默认是 auto,开启的方式多样,可以直接在命令行窗口设置临时环境变量,我是直接新建了环境变量,永久生效
其实可以直接找篇 go module 的文章,从头读下来,基本就没啥坑了,我后来随便找了篇,从头试验了下 module 的相关东西,基本就没啥问题了,比如:Golang1.12 包管理 Go module 使用
坑二:墙的问题
上面问题解决之后,重新到那个项目下 go build,当时我就在想,这现在肯定还不行,肯定还是去 golang.org 下面找包去了,肯定还是被墙,果不其然,还是不行,但是在刚才看 go module 文章的时候,看到个 goproxy 的东西,我就又重新搜索了下这个关键字,果然,有所发现,还是需要添加个环境变量 GOPROXY
有兴趣的可以去看下这个开源项目,讲道理,你自己建个都可以,我就用人家这个了。
出坑
然后再去那个开源项目下,打开命令行,go build,你就会发现一路顺畅
后记
讲道理,我并不觉得 go module 多好用,以前用的 vendor 第三方库,现在好歹官方支持了,那就暂且先用着,相信以后会越来越好,不过感觉跟 python 的 pip,node 的 npm 还是差点意思。
最后加一句,这些包的存储位置,你会发现在你 gopath 的 pkg 下面,多了个 mod 的文件夹,点开就知道了。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于