英文:
Storing a Go project with other non-Go projects
问题
当涉及到代码组织时,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社区是如何处理这个问题的?回到使用make工具吗?
英文:
When it comes to code organization, Go seem to make an assumption, that it's the only language I'm going to use. However, I'd like to treat each Go project as a yet another isolated piece of software, and store it the same way as most programs were stored for decades now - in an arbitrary directory, containing no less and no more than what is needed to build and run it.
What Go wants:
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
What I want:
home/
└─projects/
└─some-organization/
├─some-c-project/
│ └─src/
│ └─main.c
├─some-python-project/
│ └─src/
│ └─main.py
└─some-go-project/
└─src/
└─main.go
Of course, nobody prevents me from structuring it my way, but I won't be able to build/install that project the intended way anymore. Doing something like home/projects/some-organization/some-go-project/src/some-go-project/main.go
to address that is just too ugly to my liking.
So what's the consensus here? How does Go community handle this? Back-to-make?
答案1
得分: 4
我遇到了同样的问题,并尝试了以下解决方案(按时间顺序排列):
- 不要将你的包放在
$GOPATH
中,并从你的项目目录中进行编译:这在你有一个单一包的项目时有效。无论如何,Go项目应该有一个有限数量的包... - 在你的项目目录中使用符号链接到你的
$GOPATH
:每次想要检出一个新项目时都要创建符号链接真的很烦人。而且,各种要求包名称的工具(如fmt、test等)将找不到你的包,除非你反过来创建链接,这同样很烦人(而且更烦人,因为它违反了你的git布局)。 - 为每个项目添加一个像
$PATH
一样的$GOPATH
条目:比前一个解决方案更烦人,但大部分情况下有效。如果你的项目布局基于src/
目录,效果会更好。 - 使用vagrant和一个专用的
$GOPATH
:你可以按照golang的意图工作,但需要通过ssh进入虚拟机。这是我现在正在做的,因为它还具有vagrant的额外好处。
英文:
I had the same problem, and tried the following solutions (in chronological order):
- don't put you package in the
$GOPATH
and compile from your project directory: that works while you have a single-package project. Anyway, go project should have a limited number of package… - use a symlink from your project directory to your
$GOPATH
: it's really boring to have to symlink everytime you want to checkout a new project. More, the various tools asking for a package name (fmt, test, etc) won't find your package, unless you make the link the other way around, which is equally boring (even more, as it defies your git layout). - add a
$GOPATH
entry for each project (like$PATH
): even more boring than the previous solution, but mostly works. Even better if your poject layout is based on asrc/
directory. - use vagrant and a dedicated
$GOPATH
: you can work as intended by golang, with the added complexity of having to ssh into the box. That's what I am doing now, as it have the benefits of vagrant as a bonus.
答案2
得分: 4
这是一个复杂的问题,也是一个巨大的头痛,但我解决这个问题的方法是反过来做:
home/
└─projects/
├bin/
├pkg/
└─src/
└─some-organization/
├─some-go-project/
| └─main.go
├─some-c-project/
│ └─main.c
└─some-python-project/
└─main.py
我使用go的bin
和pkg
目录来存放所有语言的二进制文件和库。go的布局并不差,只是不同,将你的go代码放在一个与其他代码不同的“特殊”结构中有点丑陋,所以我更喜欢采用go的目录结构来组织我的所有项目。
好处是,你可以按照代码托管站点对所有软件项目进行分类,这很不错。
英文:
This is a complicated issue and a huge headache, but what I did to solve this issue was to do it the other way around:
home/
└─projects/
├bin/
├pkg/
└─src/
└─some-organization/
├─some-go-project/
| └─main.go
├─some-c-project/
│ └─main.c
└─some-python-project/
└─main.py
And I use the go bin
and pkg
directories for binaries and libraries of all languages. The go layout is not bad, is just different and having your go code in a 'special' structure different from all your other code is kind of ugly so I prefer to adopt the go directory structure for all my projects.
As an upside, you have all your software projects classified by repo hosting site and that is nice.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论