当谈到代码组织时,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 关注
- 185 浏览
添加回答
举报
0/150
提交
取消