liuqun

golangd 配置go mod 在博文底部

摘抄自https://studygolang.com/articles/24544 go语言中文网 在原基础博客整理增加知识点 让你彻底名表go mod
随着Go 1.13发布,GOPROXY默认值proxy.golang.org在*不能被访问。

七牛云顺势推出goproxy.cn,以利于中国开发者更好使用Go Modules,它是非盈利性的项目,首先感谢七牛云。

Windows下使用教程:

(1)升级到Go1.13

(2)运行<go env -w GO111MODULE=on> //开启mod

(3)运行<go env -w GOPROXY=https://goproxy.cn,direct> //设置七牛云goproxy代理

可以通过运行go env查看(2)、(3)步骤是否设置成功

在这里插入图片描述
(4)在项目跟目录下执行go mod init <OPTIONAL_MODULE_PATH>

执行成功后生成go.mod文件

其他指令

go get -u //更新现有的依赖
go mod tidy //整理模块(拉取缺少的模块,移除不用的模块)
go mod download//下载依赖包
go mod graph //打印现有依赖结构
go mod vendor //将依赖复制到vendor下
go mod verify //校验依赖
go.mod文件解析
module:模块名称,使用指令go mod init <OPTIONAL_MODULE_PATH>可设置
require:依赖包列表以及版本
exclude:禁用依赖包列表
replace:替换依赖包列表
go:go版本号

goland编辑器中配置go mod

在goland的setting里设置启用Go Modules
goland Preference->Go->Go Modules(vgo) -> Enable Go Modules(vgo)intergration

在这里插入图片描述

勾选 Enable Go Modules(vgo)intergration 之后 ,

proxy配置(参考上图)
https://goproxy.cn
点击apply (应用)ok 即可。

______________________________________________________________
______________________________________________________________


gomod 的相关知识 摘抄自go 夜读 (author:盛傲飞)
在这里插入图片描述
go.mod

module sss

go 1.13

require (
	github.com/astaxie/beego v1.12.0
	github.com/go-sql-driver/mysql v1.4.1
	github.com/julienschmidt/httprouter v1.3.0
	github.com/micro/examples v0.2.0
	github.com/micro/go-micro v1.18.0
)

go.mod 是启用了 Go moduels 的项目所必须的最重要的文件,它描述了当前项目(也就是当前模块)的元信息,每一行都以一个动词开头,目前有以下 5 个动词:

  • module:用于定义当前项目的模块路径。
  • go:用于设置预期的 Go 版本。
  • require:用于设置一个特定的模块版本。
  • exclude:用于从使用中排除一个特定的模块版本。
  • replace:用于将一个模块版本替换为另外一个模块版本。

这里的填写格式基本为包引用路径+版本号,另外比较特殊的是 go $version,目前从 Go1.13 的代码里来看,还只是个标识作用,暂时未知未来是否有更大的作用。
go.sum
go.sum 是类似于比如 dep 的 Gopkg.lock 的一类文件,它详细罗列了当前项目直接或间接依赖的所有模块版本,并写明了那些模块版本的 SHA-256 哈希值以备 Go 在今后的操作中保证项目所依赖的那些模块版本不会被篡改。

example.com/apple v0.1.2 h1:WX...
example.com/apple v0.1.2/go.mod h1:xHW...
example.com/banana v1.2.3/go.mod h1:HS... 
...
example.com/apple v0.1.2 h1:WXk...
example.com/apple v0.1.2/go.mod h1:xH...

前者为 Go modules 打包整个模块包文件 zip 后再进行 hash 值,而后者为针对 go.mod 的 hash 值。他们两者,要不就是同时存在,要不就是只存在 go.mod hash。

那什么情况下会不存在 zip hash 呢,就是当 Go 认为肯定用不到某个模块版本的时候就会省略它的 zip hash,就会出现不存在 zip hash,只存在 go.mod hash 的情况。

GO111MODULE
这个环境变量主要是 Go modules 的开关,主要有以下参数:

  • auto:只在项目包含了 go.mod 文件时启用 Go modules,在 Go 1.13 中仍然是默认值,详见 :golang.org/issue/31857。
  • on:无脑启用 Go modules,推荐设置,未来版本中的默认值,让 GOPATH 从此成为历史。
  • off:禁用 Go modules。

GOPROXY
这个环境变量主要是用于设置 Go 模块代理,主要如下:

  • 它的值是一个以英文逗号 “,” 分割的 Go module proxy 列表(稍后讲解)
  • 作用:用于使 Go 在后续拉取模块版本时能够脱离传统的 VCS 方式从镜像站点快速拉取。它拥有一个默认值,但很可惜 proxy.golang.org 在中国无法访问,故而建议使用 goproxy.cn 作为替代。
  • 设置为 “off” :禁止 Go 在后续操作中使用任 何 Go module proxy。

刚刚在上面,我们可以发现值列表中有 “direct” ,它又有什么作用呢?
其实值列表中的 “direct” 为特殊指示符,用于指示 Go 回源到模块版本的源地址去抓取 (比如 GitHub 等),当值列表中上一个 Go module proxy 返回 404 或 410 错误时,Go 自动尝试列表中的下一个,遇见 “direct” 时回源,遇见 EOF 时终止并抛出类似 “invalid version: unknown revision…” 的错误。

GOSUMDB
它的值是一个 Go checksum database,用于使 Go 在拉取模块版本时(无论是从源站拉取还是通过 Go module proxy 拉取)保证拉取到的模块版本数据未经篡改,也可以是“off”即禁止 Go 在后续操作中校验模块版本

  • 格式: SUMDB_NAME+PUBLIC_KEY或SUMDB_NAME+PUBLIC_KEY SUMDB_URL。
  • 拥有默认值: sum.golang.org (之所以没有按照上面的格式是因为 Go 对默认值做了特殊处理)。
  • 可被 Go module proxy 代理 (详见:Proxying a Checksum Database)。
  • GOSUMDB 的默认值在中国无法访问,故而更加建议将 GOPROXY 设置为 goproxy.cn,因为 goproxy.cn 支持代理 sum.golang.org。

Go Checksum Database
Go checksum database 主要用于保护 Go 不会从任何源头拉到被篡改过的非法 Go 模块版本,其作用(左)和工作机制(右)如下图:
在这里插入图片描述
如果有兴趣的小伙伴可以看看 Proposal: Secure the Public Go Module Ecosystem,有详细介绍其算法机制,如果想简单一点,查看 go helpmodule-auth 也是一个不错的选择。

GONOPROXY/GONOSUMDB/GOPRIVATE
这三个环境变量都是用在当前项目依赖了私有模块,也就是依赖了由 GOPROXY 指定的 Go module proxy 或由 GOSUMDB 指定 Go checksum database 无法访问到的模块时的场景,他们具有如下特性:

  • 它们三个的值都是一个以英文逗号 “,” 分割的模块路径前缀,匹配规则同 path.Match。

  • 其中 GOPRIVATE 较为特殊,它的值将作为 GONOPROXY 和 GONOSUMDB 的默认值,所以建议的最佳姿势是只是用 GOPRIVATE。

在使用上来讲,比如 GOPRIVATE=*.corp.example.com 表示所有模块路径以 corp.example.com 的下一级域名 (如 team1.corp.example.com) 为前缀的模块版本都将不经过 Go module proxy 和 Go checksum database,需要注意的是不包括 corp.example.com 本身。
Global Caching
这个主要是针对 Go modules 的全局缓存数据说明,如下:

  • 同一个模块版本的数据只缓存一份,所有其他模块共享使用。
  • 目前所有模块版本数据均缓存在 $GOPATH/pkg/mod和 $GOPATH/pkg/sum 下,未来或将移至 $GOCACHE/mod和 $GOCACHE/sum 下( 可能会在当 $GOPATH 被淘汰后)。
  • 可以使用 go clean-modcache 清理所有已缓存的模块版本数据。

另外在 Go1.11 之后 GOCACHE 已经不允许设置为 off 了,我想着这也是为了模块数据缓存移动位置做准备,因此大家应该尽快做好适配。

++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=

快速迁移项目至 Go Modules

在这里插入图片描述

  • 升级到 Go 1.13。

  • 让 GOPATH 从你的脑海中完全消失,早一步踏入未来。

    • 修改 GOBIN 路径(可选)。
    • 打开 Go modules 的开关。
    • 设置 GOPROXY。
  • 按照你喜欢的目录结构重新组织你的所有项目。

  • 在你项目的根目录下执行 go mod init<OPTIONAL_MODULE_PATH> 以生成 go.mod 文件。

  • 想办法说服你身边所有的人都去走一下前四步。

迁移后 go get 行为的改变

这里我们注意到有两点比较特别,分别是:
在这里插入图片描述

  • 第一点:为什么 “拉取 hash 为 342b231 的 commit,最终会被转换为 v0.3.2” 呢。这是因为虽然我们设置了拉取 @342b2e commit,但是因为 Go modules 会与 tag 进行对比,若发现对应的 commit 与 tag 有关联,则进行转换。
  • 第二点:为什么不建议使用 go mod vendor,因为 Go modules 正在淡化 Vendor 的概念,很有可能 Go2 就去掉了。

使用 Go Modules 时常遇见的坑

坑 1: 判断项目是否启用了 Go Modules

在这里插入图片描述

坑 2: 管理 Go 的环境变量

在这里插入图片描述
这里主要是提到 Go1.13 新增了 go env-w 用于写入环境变量,而写入的地方是 os.UserConfigDir 所返回的路径,需要注意的是 go env-w 不会覆写。

坑 3: 从 dep、glide 等迁移至 Go Modules

在这里插入图片描述
这里主要是指从旧有的依赖包管理工具(dep/glide 等)进行迁移时,因为 BUG 的原因会导致不经过 GOPROXY 的代理,解决方法有如下两个:

  • 手动创建一个 go.mod 文件,再执行 go mod tidy 进行补充。
  • 上代理,相当于不使用 GOPROXY 了。

坑 4:拉取私有模块

在这里插入图片描述
这里主要想涉及两块知识点,如下:

  • GOPROXY 是无权访问到任何人的私有模块的,所以你放心,安全性没问题。
  • GOPROXY 除了设置模块代理的地址以外,还需要增加 “direct” 特殊标识才可以成功拉取私有库。

坑 5:更新现有的模块

在这里插入图片描述

坑 6:主版本号

在这里插入图片描述

Q:使用 Go modules 时可以同时依赖同一个模块的不同的两个或者多个小版本(修订版本号不同)吗?

A:不可以的,Go modules 只可以同时依赖一个模块的不同的两个或者多个大版本(主版本号不同)。比如可以同时依赖 example.com/foobar@v1.2.3 和 example.com/foobar/v2@v2.3.4,因为他们的模块路径(module path)不同,Go modules 规定主版本号不是 v0 或者 v1 时,那么主版本号必须显式地出现在模块路径的尾部。但是,同时依赖两个或者多个小版本是不支持的。比如如果模块 A 同时直接依赖了模块 B 和模块 C,且模块 A 直接依赖的是模块 C 的 v1.0.0 版本,然后模块 B 直接依赖的是模块 C 的 v1.0.1 版本,那么最终 Go modules 会为模块 A 选用模块 C 的 v1.0.1 版本而不是模块 A 的 go.mod 文件中指明的 v1.0.0 版本。

这是因为 Go modules 认为只要主版本号不变,那么剩下的都可以直接升级采用最新的。但是如果采用了最新的结果导致项目 Break 掉了,那么 Go modules 就会 Fallback 到上一个老的版本,比如在前面的例子中就会 Fallback 到 v1.0.0 版本。

分类:

技术点:

相关文章: