GoPath模式和GoMoudle模式的相愛相殺

相信看我文章的文章的童鞋,golang版本已經是1.3版本以上。如果你的版本還停留在1.3以下,那這篇文章可以做為你的提升之法。

go moudle的前世今生

前世-gopath

gopath是什麼

GOPATH 是什麼,相信已經不用我再多說什麼瞭。大傢深受摧殘多年,應該已經有所體會。在v.1.11版本之前,安裝GO肯定要在環境變量中配置GoPath,我們可以簡單的將其理解成是工作目錄。目錄結構如下

— bin 存放編譯後生成的二進制可執行文件

— pkg 存放編譯後生成的 .a 文件

— src 存放項目的源代碼,可以是你自己寫的代碼,也可以是你 go get 下載的包

將你的包或者別人的包全部放在 $GOPATH/src 目錄下進行管理的方式,我們稱之為 GOPATH 模式。

gopath有什麼樣的問題?

版本管理問題

GOPATH 根本沒有版本的概念,如果你所應用的庫需要升級,那就是全局升級,所以涉及這個庫的服務在下一次編譯中都會使用新的庫,這是一件很危險的事情。版本管理非常重要,自己應該管理好自己的引用庫。

協同開發問題

當其他的開發者get到源碼進行修改的時候,你無法保證他下載的包是不是你所期望的版本,這及有可能導致服務出錯,且很難查找原因。

今生-GoMoudle

go modules 在 v1.11 版本正式推出,在發佈的 v1.14 版本中,官方正式發話,稱其已經足夠成熟,可以應用於生產上。

從 v1.11 開始,go env 多瞭個環境變量: GO111MODULE ,這裡的 111,其實就是 v1.11 的象征標志, go 裡好像很喜歡這樣的命名方式,比如當初 vendor 出現的時候,也多瞭個 GO15VENDOREXPERIMENT環境變量,其中 15,表示的vendor 是在 v1.5 時才誕生的。

GO111MODULE 是一個開關,通過它可以開啟或關閉 go mod 模式。

它有三個可選值:offonauto,默認值是auto

  1. GO111MODULE=off禁用模塊支持,編譯時會從GOPATHvendor文件夾中查找包。
  2. GO111MODULE=on啟用模塊支持,編譯時會忽略GOPATHvendor文件夾,隻根據 go.mod下載依賴。
  3. GO111MODULE=auto,當項目在$GOPATH/src外且項目根目錄有go.mod文件時,自動開啟模塊支持。

go mod 出現後, GOPATH(肯定沒人使用瞭) 和 GOVENDOR 將會且正在被逐步淘汰,但是若你的項目仍然要使用那些即將過時的包依賴管理方案,請註意將 GO111MODULE 置為 off。

具體怎麼設置呢?可以使用 go env 的命令,如我要開啟 go mod ,就使用這條命令

go env -w GO111MODULE="on"

go mod 使用

go mod 不再依靠 $GOPATH,使得它可以脫離 GOPATH 來創建項目

你可以在你電腦的任意位置創建一個文件夾go_demo

使用 go mod 命令初始化,此時目錄下隻有2個文件,go.mod是執行命令後生成的文件。

go mod init go_demo

文件main.go解釋:引入一個now的時間處理庫,輸出時間

package main

import (
	"fmt"

	"github.com/jinzhu/now"
)

func main() {
	fmt.Println("hello world", now.BeginningOfDay())
}

go.mod內容

module go_demo

go 1.15

require github.com/jinzhu/now v1.1.1

內容解釋:

  • 第一行:模塊的引用路徑
  • 第二行:項目使用的 go 版本
  • 第三行:項目所需的直接依賴包及其版本

此時我們在命令行執行go build進行編譯,發現多瞭一個go.sum文件,那麼這個文件又是什麼?

go.sum 文件相比go.mod就比較復雜瞭。雖然內容多,但是也不難理解。

每一行都是由 模塊路徑模塊版本哈希檢驗值 組成,其中哈希檢驗值是用來保證當前緩存的模塊不會被篡改。hash 是以h1:開頭的字符串,表示生成checksum的算法是第一版的hash算法(sha256)。

go.mod 和 go.sum 是 go modules 版本管理的指導性文件,因此 go.mod 和 go.sum 文件都應該提交到你的 Git 倉庫中去,避免其他人使用你寫項目時,重新生成的go.mod 和 go.sum 與你開發的基準版本的不一致。

go mod的好處

相比gopath的方式,go mod的好處顯而易見。你不必為瞭版本依賴費勁頭腦,模塊化自動幫你做好瞭。這就有點C#中Nuget的味道,node的npm的感覺。開發者不應為瞭這種事情操心,而應該專註於編碼問題。

go mod 命令使用

常用

go mod init:初始化go mod, 生成go.mod文件,後可接參數指定 module 名,上面已經演示過。

go mod download:手動觸發下載依賴包到本地cache(默認為$GOPATH/pkg/mod目錄)

go list -m -json all:以 json 的方式打印依賴詳情

不常用

  • go mod graph: 打印項目的模塊依賴結構
  • go mod tidy :添加缺少的包,且刪除無用的包
  • go mod verify :校驗模塊是否被篡改過
  • go mod why: 查看為什麼需要依賴
  • go mod vendor :導出項目所有依賴到vendor下
  • go mod edit :編輯go.mod文件

如何看待go moudle並應用於工作

go mode 方式肯定是推薦的一種方式,如果不是基於歷史項目-使用GOPATH,推薦盡快使用go mod方式,這能讓你省去很多糟心的事情。但是如果公司的項目還有不少就是基於gopath方式的,那你也不要著急,gopath的舊項目也是支持切換成go mod模式的,方式也很簡單,大傢動動小手,一百度就可以。當然正式的切換肯定是需要領導同意的,畢竟工作系統隨意切換還是有風險的。

參考文章

一文搞懂 Go Modules

關於我

作者博客|文章首發

到此這篇關於GoPath模式和GoMoudle模式的相愛相殺的文章就介紹到這瞭,更多相關GoPath模式和GoMoudle模式內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: