在GOPATH之外拥有Go项目的源代码是一个坏主意

我正在使用Go进行一个新项目，而我们都是Go的新手。我们遵循标准的go目录结构，并将所有代码置于

$ GOPATH / src / github.com / companyname / projectname

这也是git仓库的根

推荐的标准路径布局确实有些奇怪，特别是如果我们正在开发多语言项目，例如基于Go的rest / http后端和html / javascript前端。在这种情况下，我可能希望我的项目结构如下所示：

/
  doc/
  src/
    server/
      main.go
      module1/
        module.go
    client/
      index.html
  Makefile

但是实际上是否需要将代码放置在GOPATH中？

作为尝试，我创建了一个小程序，其中的源代码在GOPATH之外。我可以轻松地将项目拆分为多个包，因此该main包可以使用引用文件夹中的一个foo包。foo/import "./foo"

据我所知，有两件事使我无法接受：

• 其他代码无法导入此代码。这不是问题，因为我们正在为公司专门构建服务。
• 我不能go install用来安装它。这也不是问题。构建管道将安装该工具。

但是，它确实允许构建服务器的工作区不位于GOPATH内

不鼓励这种方法吗？如果是这样，为什么呢？

除了我列出的两个副作用之外，还有其他副作用吗？

请记住，这是公司的私人项目，而不是公开的开源代码。

将实际项目从GOPATH中分离出来似乎很诱人，但是当您处于Shu阶段时，应该小心打破规则

您不需要使用GOPATH，但是会错过从go命令中获得的所有出色工具。他们都希望代码位于标准的GOPATH层次结构中。

您提到了go install，但是go test（以及不错的go test -cover覆盖率工具）也无法使用go get，它允许您下载远程代码，将所有内容写入GOPATH，因此您需要将内容复制过来。

当然，您可以将其全部替换为make / scons / cmake / whatever，然后将其完成，这可能会在您的环境中起作用，但是它可以由该go工具完成。

（免责声明：我喜欢设计这样的东西，但我是Go的新手，我没有在实践中尝试过）

想法：为什么两者都不是？

如果考虑符号链接，则有两个可用的极性选项：

（A）src中的代码，符号链接到工作区

/
  doc/
  src/
    server/
      projectname/
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname -> ../../../src/server/projectname
      github.com/
        someone/
          library/
    bin/
    pkg/
  Makefile

（B）工作区中的代码，符号链接到src

/
  doc/
  src/
    server/
      projectname -> ../../go_workspace/src/companyname/projectname
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname/
      github.com/
        someone/
          somelib/
    bin/
    pkg/
  Makefile

我倾向于“ A”，因为：

• 您所有的资源在物理上都紧密联系在一起，
• projectname 可以轻松拥有自己的存储库，也可以为整个项目拥有一个存储库，
• 您可以使整个go_workspace版本保持原状，并通过make步骤对其进行初始化（使用godep然后符号链接项目）

2019更新

您不再需要将项目存储在下面GOPATH。

只需将其放在之外的任何目录中即可GOPATH。然后输入：

go mod init github.com/youruser/yourproject

你会好起来的。