當談到代碼組織時,Go 似乎做出了一個假設,即它是我將要使用的唯一語言。但是,我想將每個 Go 項目視為另一個獨立的軟件,并將其存儲方式與幾十年來大多數程序的存儲方式相同 - 在任意目錄中,包含不少于所需的內容來構建和運行它。Go 想要什么:home/├─go/│ └─src/│ └─some-organization/│ └─some-go-project/│ └─main.go└─projects/ └─some-organization/ ├─some-c-project/ │ └─src/ │ └─main.c └─some-python-project/ └─src/ └─main.py我想要的是:home/└─projects/ └─some-organization/ ├─some-c-project/ │ └─src/ │ └─main.c ├─some-python-project/ │ └─src/ │ └─main.py └─some-go-project/ └─src/ └─main.go當然,沒有人阻止我按照自己的方式構建它,但是我將無法再以預期的方式構建/安裝該項目。做一些類似的事情home/projects/some-organization/some-go-project/src/some-go-project/main.go來解決這個問題對我來說太難看了。那么這里的共識是什么?Go 社區如何處理這個問題?返工?
2 回答

偶然的你
TA貢獻1841條經驗 獲得超3個贊
我遇到了同樣的問題,并嘗試了以下解決方案(按時間順序):
不要把你的包放在你
$GOPATH
的項目目錄中并從你的項目目錄中編譯:當你有一個單包項目時它可以工作。無論如何,go 項目應該有數量有限的包……使用從你的項目目錄到你
$GOPATH
的符號鏈接:每次你想簽出一個新項目時都必須符號鏈接真的很無聊。此外,要求包名的各種工具(fmt、test 等)不會找到你的包,除非你把鏈接反過來,這同樣無聊(甚至更多,因為它違背了你的 git 布局)。$GOPATH
為每個項目添加一個條目(如$PATH
):比以前的解決方案更無聊,但大部分都有效。如果您的項目布局基于src/
目錄,那就更好了。使用 vagrant 和一個專用的
$GOPATH
: 您可以按照 golang 的預期工作,但增加了必須通過 ssh 進入框的復雜性。這就是我現在正在做的事情,因為它具有 vagrant 的好處作為獎勵。
- 2 回答
- 0 關注
- 210 瀏覽
添加回答
舉報
0/150
提交
取消