我一直在玩 Go 模塊，我想知道以下目錄結構的最佳實踐是什么：project├── go.mod├── main.go└── players? ? ├── go.mod? ? ├── players.go? ? └── players_test.goplayers一開始我在將包導入我的根項目時遇到問題，但我注意到我可以在根go.mod文件中執行此操作module github.com/<name>/<project>require (? ? github.com/<name>/players v0.0.0)replace github.com/<name>/players => ./playersimport "github.com/<name>/players"這讓我可以在我的文件中做main.go。現在這種方法有效并且是從這里獲取的，但我不確定這是否是正確的方法，或者這種方法是否只是為了在版本控制之外臨時更新本地包。另一種選擇，似乎有點矯枉過正，是讓每個模塊都有自己的存儲庫？長話短說，- 在同一個存儲庫中擁有多個模塊并將它們導入其他模塊/根main.go文件的最佳實踐方法是什么？
2 回答
繁華開滿天機
TA貢獻1816條經驗 獲得超4個贊
一般來說，模塊應該是包的集合。
但是您仍然可以創建單個包的模塊。這可能只有在您希望這些包具有不同的生命周期時才有意義。當您想從另一個項目導入這些模塊并且不希望整個包集合的開銷時，它也可能有意義。
一般來說：
模塊是相關的 Go 包的集合，它們作為一個單元一起進行版本控制。
模塊記錄精確的依賴需求并創建可重現的構建。
大多數情況下，版本控制存儲庫只包含一個在存儲庫根目錄中定義的模塊。（單個存儲庫支持多個模塊，但通常這會比每個存儲庫一個模塊導致更多的持續工作）。
總結存儲庫、模塊和包之間的關系：
一個存儲庫包含一個或多個 Go 模塊。2.每個模塊包含一個或多個Go包。3. 每個包由一個或多個 Go 源文件組成，位于一個目錄中。
互換的青春
一
TA貢獻1797條經驗 獲得超6個贊
我知道這是一個老問題，但是在一個存儲庫中管理多個模塊時，有一些更多的細節值得一提，無論有沒有go.work.
長話短說
每種方法都有利有弊，但如果您正在處理包含許多模塊的大型代碼庫，我建議堅持使用基于提交或標簽的版本處理，并使用 Go Workspace 進行日常開發。
轉到模塊詳細信息
replace沒有版本控制的指令
當你使用replace指向本地目錄的指令時，你會發現依賴模塊的版本為v0.0.0-00010101000000-000000000000.?基本上你得不到版本信息。
使用模塊路徑go.mod定義的主要模塊無法進行可重現的構建，因為指令的依賴目標可能已更新其內容。如果許多模塊使用的依賴目標，這可能會特別成問題。這種通用包中的任何更改都可能同時導致所有依賴項的行為更改。github.com/name/projectgithub.com/name/projectreplacegithub.com/name/project/players
如果那不是您關心的問題，replace指令應該絕對可以正常工作。在這樣的設置中，go.work可能是您并不真正需要的層。
有版本控制
如果您想確保版本設置適用于多個模塊的可重現和確定性構建，您可以采用幾種不同的方法。
一go.mod，一個存儲庫
這可能是最簡單的方法。對于每個模塊，都有清晰的提交歷史記錄和版本控制。只要您通過遠程存儲庫引用模塊，這可能是最簡單的設置，并且依賴設置非常清晰。
但是，請注意，這種方法意味著您需要管理多個存儲庫，并且提供go.work幫助將需要適當的本地目錄映射，這對于代碼庫的新手來說可能很困難。
基于提交的版本控制
仍然可以使用版本信息確定性地定義依賴關系，以便您可以在單個存儲庫中構建代碼?；谔峤坏姆椒ㄐ枰钌俚牟襟E，并且仍然可以很好地工作。不過，有一些問題需要注意。
要
github.com/name/project對 具有依賴性github.com/name/project/players，您需要確保所需的代碼在遠程存儲庫中。這是因為github.com/name/project將從遠程存儲庫中提取代碼和提交信息，即使存儲庫的本地副本上有相同的代碼也是如此。這確保了從提交引用中獲取的版本github.com/name/project/players，例如v0.1.1-0.20220418015705-5f504416395d(ref:?details of "pseudo-version"?)模塊名稱必須與目錄結構匹配。例如，如果您有單個存儲庫
github.com/name/project和模塊/src/mymodule/，則模塊名稱必須是github.com/name/project/src/mymodule。這是因為當模塊路徑解析發生時，Go 會找到存儲庫的根目錄（在上面的示例中，這將是github.com/name/project.git），然后嘗試根據模塊名稱跟蹤目錄路徑。如果您在私有存儲庫中工作，則需要確保
go.sum檢查不會阻止您。您可以簡單地使用GOPRIVATE=github.com/name/project來指定您不希望跳過校驗和驗證的路徑。
基于標簽的版本控制
除了使用提交 SHA，您還可以使用 Git 標簽。
但是因為一個存儲庫中可能有很多模塊，Go Module 需要找到哪個標簽映射到哪個。例如，具有以下目錄結構：
# All assumed to be using `github.com/name/project` prefix before package name
mypackage/? ? ? ? ? # v1.0.0
anotherpackage/? ? ?# v0.5.1
nested/dependency/? # v0.8.3
您將需要在 中創建標簽github.com/name/project，其名稱與目錄結構完全匹配，例如：
mypackage/v1.0.0
anotherpackage/v0.5.1
nested/dependency/v0.8.3
這樣，每個標簽都被 Go Module 正確引用，并且您的依賴關系可以保持確定性。
go.work行為
如果您go.work在父目錄上有go work use github.com/name/project/players等，則優先使用本地文件。即使您在go.mod.
對于跨多個項目的本地開發，Go Workspace 是一種同時處理多個事物的好方法，而無需先推送依賴項的代碼更改。但與此同時，實際發布仍然需要分解提交，以便稍后在其他代碼更改中引用第一次提交。
go.work據說是您很少需要提交到存儲庫的文件。不過，您必須了解在父路徑中具有的影響go.work。
- 2 回答
- 0 關注
- 158 瀏覽
添加回答
舉報
0/150
提交
取消