什么时候真的有必要将 Go 源代码放在 $GOPATH/src 中？

Question

看看这个 shell 会话，我在其中用 Go 构建了一个简单的 hello world 程序。

$ cd ~/lab/hello/
$ ls
hello.go
$ cat hello.go 
package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
}
$ go build
$ ./hello 
hello, world
$ go env
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.7 (jessie)
Release:    8.7
Codename:   jessie

这是我不明白的地方。 https://golang.org/doc/install#testing 的教程说我应该将我的 hello.go 文件放在 ~/go/src/hello。但我没有遵循这个。那么我的程序是如何编译的呢？如果我的程序以这种方式编译正常，为什么文档说我应该将我的源代码保留在 ~/go/src 或 $GOPATH/src 而这似乎无关紧要？

是否存在真的需要将源代码放在$GOPATH/src的场景？

Answer 1

标准 Go 工具在 $GOPATH 子目录 src、pkg 和 bin 中查找。例如，

currency.go:

package main

import (
    "fmt"
    "time"

    "golang.org/x/text/currency"
)

func main() {
    t1799, _ := time.Parse("2006-01-02", "1799-01-01")
    for it := currency.Query(currency.Date(t1799)); it.Next(); {
        from := ""
        if t, ok := it.From(); ok {
            from = t.Format("2006-01-01")
        }
        fmt.Printf("%v is used in %v since: %v\n", it.Unit(), it.Region(), from)
    }
}

输出：

$ go build currency.go
currency.go:7:2: cannot find package "golang.org/x/text/currency" in any of:
    /home/peter/go/src/golang.org/x/text/currency (from $GOROOT)
    /home/peter/gopath/src/golang.org/x/text/currency (from $GOPATH)
$

如果我们将丢失的包放在 $GOPATH/src 中，标准的 Go 工具会找到它。

$ go get golang.org/x/text/currency
$ go build currency.go
$ ./currency
GBP is used in GB since: 1694-07-07
GIP is used in GI since: 1713-01-01
USD is used in US since: 1792-01-01
$

Answer 2

正如 JimB 在他的评论中所说，Go documentation 清楚地表明了这一点；基本上，GOPATH 是 workspace，它允许您将所有项目文件以及导入和工件保存在一个位置。

对于一个简单的项目来说，这并不是绝对必要的，但是当您开始导入依赖项并想要管理库时，它会变得更有帮助。

Answer 3

你真的需要将你的代码放在 GOPATH 中，一旦你写了超过 package main。当你 import "github.com/me/myapp/mylib" 时，Go 会在你的 GOPATH 下查找。 go test 等工具也适用于 GOPATH 下的包，而不是 .go 文件。

一旦您的代码位于多个文件中，这也变得更加实用。这就像通过直接调用 cc/gcc/etc 来编译你的 C 程序的区别。并使用像 make.

这样的工具

如果您一开始就想知道为什么人们首先要将项目分解成多个包，原因包括：

项目在增长，您确实需要组织 10K 或 100K 行。
项目通常包含可重复使用的工具，包让其他项目 import 单独使用它们。
包让您可以跟踪和控制哪些代码可以访问哪些其他代码和变量。例如，一个包中的私有名称无法被其他包访问，因此您知道您可以在不破坏包外代码的情况下随意使用这些私有名称，并且您知道外面没有任何代码与 private fields/variables 混淆或在背后调用私人代码。
包最小化命名空间冲突，即，您可以有 gzip.Reader 和 io.Reader。如果您选择正确的名字，packagename.ThingName 可以让代码自然阅读。
包可以单独重新编译、测试等，这让您的 edit/build/test 周期更快。
具体来说，在 Go 中，包强制执行关于代码组织的一些其他事情，比如没有循环依赖（如果 A 导入 B，B 不直接或间接导入 A）并且 /foo/internal/ 下的包只得到/foo/ 下的软件包使用。像这样的约束可以帮助防止一个大项目像意大利面条一样乱七八糟地结束。

还有其他好处，但这些应该有助于说明为什么值得养成这个习惯。把一些东西放在一个大包中，然后开始分解文件，根据需要将一些类型、函数等移到其他包中，这很好；随着时间的推移，'natural' 边界将开始变得更有意义。

什么时候真的有必要将 Go 源代码放在 $GOPATH/src 中？

When is it really necessary to place Go source code in $GOPATH/src?

projects-and-solutions

directory-structure

go