go 🚀 - cmd/go: 假设 GOPATH=$HOME/go 如果没有设置

/cc @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

bradfitz 于 2016-09-28

我喜欢它，但是我们对“gocode”有什么特别的偏好，而不是像“gopath”这样的东西？

campoy 于 2016-09-28

有多少人已经在使用 GOPATH=$HOME/gocode？在我看来并不多。这表明这是错误的默认值。

rsc 于 2016-09-28

👍27

“gocode”与流行的工具 github.com/nsf/gocode 会有搜索引擎和其他混淆。

cespare 于 2016-09-28

😕2

我们有关于大多数人做什么的任何信息吗？

我自己使用 GOPATH=$HOME/gopath 。

ianlancetaylor 于 2016-09-28

👍8 👎5

如果您当前使用 GOPATH=$HOME，请在此处竖起大拇指

bradfitz 于 2016-09-28

👍69 👎52 😄2

如果您当前使用 GOPATH=$HOME/gopath，请在此处竖起大拇指

bradfitz 于 2016-09-28

👍45 👎43

如果您当前使用 GOPATH=$HOME/gocode，请在此处竖起大拇指

bradfitz 于 2016-09-28

👎43 👍28

我应该在@golang 上进行推特民意调查吗？

campoy 于 2016-09-28

@campoy ，听起来不错。可能比邀请所有人参与此错误更好。

bradfitz 于 2016-09-28

$HOME/go 怎么样（这是我使用的）。

freeformz 于 2016-09-28

👍194 🎉12 👎1

另见： http :

$HOME：8.9%
$HOME/去：50.6%
其他 : 40.5%

我真的希望我为这个选择了更多的选择。

freeformz 于 2016-09-28

👍2

投票开始： https :

2016 年 9 月 28 日，星期三，上午 10:51 Edward Muller通知@ github.com
写道：

$HOME/go 怎么样（这是我使用的）。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -250244110，或者静音
线程
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

campoy 于 2016-09-28

😕4

另请参阅此处的第一列： https ://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid =1525640201

freeformz 于 2016-09-28

@freeformz ，

$HOME/go 与 go 源代码 (go.googlesource.com/go) 经常被检出的路径冲突。不幸的是，社区将此位置作为 GOPATH 的默认位置进行了祝福:( 我担心如果有人忘记设置他们的 GOPATH 并运行 go 工具，它会弄乱他们当前的开发目录。

rakyll 于 2016-09-28

👍9

@rakyll给他们自己的，只是想表明我和许多其他人使用什么。 go.googlesource.com/go 在我的系统上的 /usr/local/go.git 中检出。

freeformz 于 2016-09-28

👍2

有多少人已经在使用 GOPATH=$HOME/gocode？在我看来并不多。这表明这是错误的默认值。

作为记录，我使用GOPATH=$HOME ，但我觉得这太有争议了，并且有损于该提案的目标，即改善新用户的体验。

davecheney 于 2016-09-28

@freeformz ，我想我们不必关心 $HOME 之外的现有规范路径。 GOPATH 的默认值将在 $HOME 某处，最低要求应该是它不与任何关键的现有路径冲突。

$HOME/gocode 对我来说听起来很陌生，但它可能是一个非常好的选择。

rakyll 于 2016-09-28

关键是，默认值是什么并不重要，只是有一个。

davecheney 于 2016-09-28

👍7

默认值是什么很重要，因为设置这个默认值本质上会让每个 Go 新手在几年后的工作方式。

当 GOPATH=$GOROOT 明确时，go 命令会尽力避免混淆；我确信同样的逻辑也可以应用于 am 隐式设置。所以我不太担心不小心砸了 $HOME/go。

我仍然想知道我们是否应该自动嗅探当前目录的父目录来找出 GOPATH 的位置，而不是固定的默认值。这就是当今许多源工具所做的（例如，每个版本控制系统），因此这是人们会理解的概念。并且它不会强制他们使用一个目录名称或只有一个 GOPATH 工作区。但我们不妨就原始问题进行讨论。

rsc 于 2016-09-28

👍10

@rsc我希望默认值为GOPATH=$HOME因为这意味着$GOPATH/bin将在他们的路径中（至少在大多数 linux 发行版上，不确定 darwin）。

$GOPATH=$HOME/go也是一个不错的选择，那些在那里检查过编译器源代码的人已经设置了GOPATH=something else所以不会有冲突的可能性。

说清楚，我说的时候并不是要轻率

关键是，默认值是什么并不重要，只是有一个。

而是试图强调该提案的目标是让 go 工具在没有提供$GOPATH时使用默认值，因为这对许多语言新手来说是一个持续的困惑和沮丧的根源。

我正在使用 👎 自动嗅探，因为它在一个主要用例中失败了，即：

我已经安装了 Go，我实际上并没有阅读 Go 安装文档，只是按照它在 repo 的自述文件中所说的brew install go
我已经跑了go get github.com/thething/theproject
现在我收到关于未设置 $GOPATH 的错误。那是什么？我只是想运行这个有人在推特上提到的程序！

davecheney 于 2016-09-28

👍9

GOPATH=$HOME/go SGTM 的默认值，假设我们决定使用默认值而不是自动嗅探方法。

adg 于 2016-09-28

👍14

当 GOPATH=$GOROOT 明确时，go 命令会尽力避免混淆；我确信同样的逻辑也可以应用于 am 隐式设置。

听起来很棒。

不知道达尔文

不是在达尔文。

rakyll 于 2016-09-28

👍1

如果这是针对新人的，我建议不要使用GOPATH=$HOME因为这会在他们的主目录中创建三个目录而不是一个。我不热衷于不必要地污染我的家庭目录的软件。

mvdan 于 2016-09-28

👍25

@mvdan我理解，你的反应是我没有提出GOPATH=$HOME 。

如果 _I_ 个人想将我的GOPATH为$HOME ，那么我仍然可以使用该选项，并且如果 Go 1.8 接受此提议，我将不必进行任何更改。

davecheney 于 2016-09-28

@davecheney

默认值为 GOPATH=$HOME/gocode

Windows 上没有默认的 HOME 变量。你建议在 Windows 上做什么？

我希望默认为 GOPATH=$HOME 因为这意味着 $GOPATH/bin 将在他们的路径中

我总是担心在我的 PATH 中有 $GOPATH/bin。 go get在那里安装其他人的程序。我们真的希望新的 Go 用户在他们的 PATH 中某处安装来自互联网的随机程序吗？

亚历克斯

alexbrainman 于 2016-09-29

👍4

我不是经验丰富的 Windows 用户，但我认为存在存储文档和设置的基本路径的一些概念。出于本次讨论的目的，假设我在 Windows 用户的上下文中讨论该路径。

如果不存在这样的路径，则假定为 C:/gocode。

根据我对 GOPATH=$HOME 的评论，虽然这是并将继续是我的个人偏好，但我认识到这是一个有争议的默认值选项，因此不建议将其作为建议值。

davecheney 于 2016-09-29

👍1

自动检测充满危险。不久前我开始对此进行原型设计，但它给 go 工具和用户体验都增加了显着的复杂性。

我不了解包管理工作组正在发生的事情，但我可以想象在不久的将来完全消除 GOPATH。

也就是说，即使 GOPATH 在不久的将来确实消失了，设置默认值可能仍然有价值。如果我们确实认为 GOPATH 可能会消失，那么我们将其设置为什么并不重要。

从我上面读到的，有一些共识：

默认情况下， GOPATH=$HOME太具有侵入性。
默认值应在某处包含字符串go （可能作为前缀）。

我不担心 GOPATH 是主要 go repo 的克隆（即，GOPATH == GOROOT）。查看 go repo 的人可能已经设置了 GOPATH。 go 工具无论如何都会检测到冲突，就像今天一样。

考虑到这一点，最简洁的默认值是$HOME/go ，我认为这是非常合理的。

broady 于 2016-09-29

👍6

我假设存在存储文档和设置的基本路径的一些概念。

我不知道这样的事情。也许其他 Windows 用户会在这里发表评论。

如果不存在这样的路径，则假定为 C:/gocode。

你想要 C:gocode 代替。
将东西放在 C:\ 的根目录中对我来说听起来不对。你会建议在 Linux 上将 GOPATH 设置为 /gocode 吗？
但是，鉴于 Windows 安装程序已经将 Go 安装到 C:go 中，GOPATH 的 C:gocode 至少是一致的。

亚历克斯

alexbrainman 于 2016-09-29

👍1

但是，鉴于 Windows 安装程序已经将 Go 安装到 C:go 中，GOPATH 的 C:gocode 至少是一致的。

不应该为每个用户提供 GOPATH 吗？我想与 UNIX 相同， %USERPROFILE%\gocode 。

mattn 于 2016-09-29

👍2

Go+ 投票在https://goo.gl/xAsgEj

cznic 于 2016-09-29

在我使用了很长时间后，例如 $HOME/go-programs 我将 GOPATH 切换到 $HOME。所以，现在我有以下结构：

$HOME/bin
$HOME/包
$首页/源代码/
$HOME/src/github.com/user/some_github_project
$HOME/src/some_project

这种结构更通用，也可用于与其他语言或项目以及 github 一起使用。例如，我有 $HOME/src/talks（在 home/sources/talks 中阅读降价文件）或某些语言的其他项目（如 $HOME/src/github.com/user/html）但也有来源，我有一个有或没有 github 通信的许多项目源的地方。

bin 或 pkg 可以被认为是凌乱的，但我认为并没有那么烦人。对于使用多种语言的人来说，有很多源文件夹会更麻烦。

所以，从我的角度来看，最好的 GOPATH 位置是 $HOME。

geosoft1 于 2016-09-29

我使用 $HOME/gocode 作为我的 GOPATH。
我反对 $HOME/go 因为有时你没有 root 权限，你需要在你的主目录下安装 Go。在这种情况下，我认为 $HOME/go 最适合 GOROOT。
所以我们应该使用与 $HOME/go 不同的东西作为 GOPATH。

hnakamur 于 2016-09-29

👍5 👎1

@hnakamur当我手动安装 Go 时（现在使用 Ubuntu Make），我把它放在 $HOME/bin/go-${go_version} （带有从 $HOME/bin/go 到 $HOME/bin/go-$ 的符号链接{version}/bin/go，所以我不必编辑我的 $PATH）

tbroyer 于 2016-09-29

👍2

@tbroyer这是利基市场。我猜大多数用户不想要额外的配置或设置。在我看来， ~/bin 已经用于放置自己的脚本或二进制文件（像我一样）。而且我认为 ~/bin (~/src, ~/pkg) 使删除 go 二进制文件有点困难。

mattn 于 2016-09-29

我将 $HOME 用于我的 GOPATH。
为什么自动设置 GOPATH，为什么不发出带有良好信息的警告，如果 GOPATH 不存在，如何设置它？

dvrkps 于 2016-09-29

👍1

为什么自动设置 GOPATH，为什么不发出带有良好信息的警告，如果 GOPATH 不存在，如何设置它？

问题不在于人们不知道如何设置环境变量（在大多数情况下），而是即使你这样做了，在开始使用 Go 时不得不跳过箍也感觉很糟糕。能够在安装后立即使用具有合理默认值的 Go 使体验尽可能无缝，这意味着更多的人可能会在下载后实际尝试 Go，而不是遇到障碍，失去动力，并且决定它不值得搞砸。

SamWhited 于 2016-09-29

👍6

我倾向于同意 Chris 和 Andrew：如果有一个默认的 GOPATH，它应该只是 $HOME/go，而不是 gopath 或 gocode。 _大多数_用户没有在那里检查 Go 发行版（今天这样做的每个人都已经设置了 GOPATH，所以这不会打扰他们）。默认值需要对新用户有意义，而不是高级用户，对于大多数用户来说，$HOME/go 很有意义。

Jaana 担心如果 $HOME/go 恰好是 Go 发行版，go 命令会变得混乱，但是 go 命令已经检查了意外的 GOPATH=$GOROOT。当 GOPATH 也隐式设置时，很容易检查这是否正确。事实上，增加检查也很容易，例如，$HOME/go/src/cmd/go/alldocs.go，以避免混淆，即使 GOROOT!=$HOME/go 但 $HOME/go 确实如此包含一个 Go 发行版。

rsc 于 2016-09-29

👍17

$HOME/go 不是 GOPATH 的好选择。让我们做一个简单的行为练习......新用户可以轻松地将默认设置视为最佳实践。假设我是一个新用户，为什么我应该认为默认值是一件坏事？不仅如此，安装 golang 的最简单（也是最好的？）方法是在 $HOME 中解压，因为使用这种方法，编译器始终处于最新版本并且不需要 root 权限，因此您可以轻松假设许多用户将拥有 go 编译器在 $HOME/go. 为什么我应该在 /usr/local 中移动编译器，而我根本没有呢？
不仅如此，他们还可以制作项目并可以在此文件夹中克隆项目。所以，他们会有一个凌乱的文件夹，稍不注意他们就可以通过重新安装新的 golang 轻松删除他们的项目文件夹。
此外，Windows 用户默认使用 c:go。

geosoft1 于 2016-09-29

我喜欢 $HOME/gopath。它说它是什么。
在 Google 上搜索“gopath”的第一个结果是正确的页面。

randall77 于 2016-09-29

👍4

如果采用默认值，是否可以将func GOPATH() string函数添加到runtime ？现在可以使用os.Getenv() ，但默认情况下它不会那么简单。

btracey 于 2016-09-30

@btracey ， GOPATH 是一个列表，而不是单个值。使用filepath.SplitList 。此外， GOPATH 不是运行时的函数。它只涉及cmd/go 。

bradfitz 于 2016-09-30

为了向后兼容，我们可能需要在进程中设置 GOPATH'
如果没有设置环境。

2016 年 9 月 30 日 08:10，Brendan Tracey通知@github.com
写道：

如果采用默认值，是否可以添加 func GOPATH() 字符串函数
运行时？现在可以使用 os.Getenv()，但使用默认值
不会那么简单。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -250605418，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

adg 于 2016-09-30

你是对的@bradfitz。 @adg提出的解决方案将满足我的所有用途。

btracey 于 2016-09-30

这是一个有趣的皱纹。当没有时，我可以看到当前失败
GOPATH 设置好了，也是当 GOPATH 包含多个值时，然后
有些情况下，应用程序构建在一台机器上并部署在
其他。

我不想忽略 GOPATH 的这种用法，我理解这种痛苦
能够为您的应用程序找到支持文件，但我想
了解这种用法的广泛程度，以及当前的
实现处理我上面强调的问题。

在周五，2016年9月30日，08:35布伦丹·特蕾西[email protected]写道：

你是对的@bradfitz https://github.com/bradfitz。解决方案
@adg https://github.com/adg提出的将满足我的所有用途。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -250611813，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

davecheney 于 2016-09-30

我的用法不是正常的。我做科学研究，我发现不仅有gopath/src和gopath/bin ，还有gopath/data和gopath/results 。这使得将源文件复制到新系统变得容易，而无需复制（千兆字节）结果文件。新系统（比如集群）生成新的结果文件，我可以将这些结果复制到一个中央位置。然后说gopath = os.Getenv("GOPATH")并将文件保存到filepath.Join(gopath, "results", "projectname", result.json)类的内容真的很容易。

btracey 于 2016-09-30

谢谢你。明确地说，我并不是要暗示您的用法不正确或
错了，我只是想了解一下 GOPATH wrt 的这种用法
我强调的限制。

在周五，2016年9月30日，09:09布伦丹·特蕾西[email protected]写道：

我的用法不是正常的。我做科学研究，我发现
不仅有 gopath/src 和 gopath/bin 非常有效，而且
gopath/data 和 gopath/results。这使得复制源变得容易
将文件转移到新系统，而无需复制（千兆字节）
结果文件。新系统（比如集群）生成新的结果文件，
我可以将这些结果复制到一个中心位置。这真的很容易
然后说 gopath = os.Getenv("GOPATH")，并将文件保存到类似 filepath.Join(gopath,
“结果”、“项目名称”、result.json）。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -250617618，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

davecheney 于 2016-09-30

如果您目前使用GOPATH=$HOME/.go ，请在此处竖起大拇指

douglarek 于 2016-09-30

👍5

@davecheney没有冒犯，只是想提供足够有用的上下文。

btracey 于 2016-09-30

让我们不要在讨论中使用 GOPATH 来查找支持文件。

（GOPATH 旨在作为编译时设置，而不是运行时设置。我知道人们有时会模糊这些设置并在运行时使用 GOPATH 查找相关文件，但我认为我们不应该鼓励这样做或使它更容易做到。我们需要一个更好的支持文件的故事，但这应该是一个单独的问题。）

rsc 于 2016-09-30

👍6

与在运行时查找关联文件相关：#12773

randall77 于 2016-09-30

很抱歉再次污染讨论@rsc ，但是@randall77 ， #12773 比直接解决这个问题更难使用。需要文件（或保存文件）的特定代码可以移动很多，我希望输入/输出的固定位置独立于（和分离于）重构。

btracey 于 2016-09-30

这个问题是关于 GOPATH 的一个可能的默认值。它_不是_关于 GOPATH 的替代用途。

rsc 于 2016-09-30

如果此更改的目标用户只是那些只想
安装一个用 Go 编写的新程序，而不是那些真正想要的程序
写 Go，然后我们让 go 在每个用户的目录中克隆
$TMPDIR，如果未设置 $GOPATH，则将二进制文件保留在 $PWD？（明显地
这仅对 go get import.path/for/a/command 有意义，如果它不是
命令，go get 应该在没有设置 $GOPATH 的情况下失败）

对于外行来说，这很有意义，就像 wget 一个文件一样。

一旦用户想要开始编写 Go 代码，他们应该学习如何设置
GOPATH 正确。

minux 于 2016-10-01

👍2

我反对 $HOME/go 因为有时你没有 root 权限，你需要在你的主目录下安装 Go。在这种情况下，我认为 $HOME/go 最适合 GOROOT。

如果您使用的是 Linux 系统，我认为 $GOROOT 的最佳位置可能是 $HOME/.local/opt/go，而不是 $HOME/go，这取决于您如何解释 $HOME/.local 的目的，因为在 XDG 基本目录规范中仅定义了 $HOME/.local/share（似乎是 /usr/local/share 的镜像）： https :

人们也可能会争辩说 GOPATH / GOBIN（在 Linux 上）的最佳默认值应该是：
GOPATH=$XDG_DATA_HOME/go 或 $HOME/.local/share/go
GOBIN=$HOME/.local/bin

但是，对于新用户来说，这可能不是最容易理解的？而且它也不清楚什么是 Windows 上的最佳方法。 $HOME/go 和 $USERPROFILE/go 看起来很实用。

smyrman 于 2016-10-02

👍4 👎3

请_请_让我们不要让这个线程变成对规范 Linux 路径名和存储位置的讨论。它没有成效，而且我觉得这个讨论已经偏离了 Dave Cheney 最初的帖子。

我也不确定实际的绝对位置是否重要，我认为这个线程真正需要决定的是“我们想要一个默认的 Gopath 吗？” （听起来这或多或少是压倒性的）和“它应该在系统范围内共享，还是在用户本地共享”（到目前为止，大多数讨论都是关于本地的）。在那之后，任何实施者都可以选择$HOME/gocode或$HOME/go或/usr/share/go/或他们想要的任何对审查 PR 的人来说似乎合理的任何东西，并且事情可能会继续很好。

SamWhited 于 2016-10-03

👍4

我认为由于权限问题，系统范围的 GOPATH 是非启动器。

adg 于 2016-10-03

👍4

系统范围的路径，无论好坏，都是 GOROOT，它的发行版
就像 debian 用于安装“系统范围”软件包一样，为了更好或为了
更差。

系统范围的 GOPATH 超出了本提案的范围，本提案
推荐从登录用户的值派生的路径。

2016 年 10 月 4 日，星期二，08:52 Andrew Gerrand [email protected]写道：

我认为由于权限问题，系统范围的 GOPATH 是非启动器。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -251238251，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

davecheney 于 2016-10-04

👍1

请不要让这个线程变成对规范 Linux 路径名和存储位置的讨论。它没有生产力

好吧，我们不要。我的主要观点实际上是指出 $HOME/go 作为 GOPATH 默认值可能没有问题的另一个原因，因为它可能不是本地用户安装 Go（又名 GOROOT）的最“惯用的 Linux”路径。

除此之外，我相信之前已经

smyrman 于 2016-10-04

$HOME/工作......

dup2X 于 2016-10-11

@adg @quentinmit @rsc此提案的下一步是什么？

davecheney 于 2016-10-24

真的很想看到这里发生一些事情。这是我课堂上经常遇到的痛点。任何默认值（即使是我不同意的 $home/go :) ）总比没有好。

bketelsen 于 2016-10-24

$HOME/go 会的。没有单一的最佳答案，但这是简短而甜蜜的，如果 $HOME/go 已经存在，选择该名称只会是一个问题，这只会让已经安装了 go 并且会理解 GOPATH 的专家感到高兴。

robpike 于 2016-10-25

👍53 🎉20 ❤4

谁愿意做这项工作？

adg 于 2016-10-25

我肯定很乐意为此工作。

campoy 于 2016-10-25

👍2

@campoy ，你能做到吗<=这个星期五？

bradfitz 于 2016-10-25

我会这么说，是的@bradfitz 。这听起来不像是要完成大量的代码。
我明天就可以开始了。

campoy 于 2016-10-25

更新：我快速浏览了一下，已经写了一些代码，今天晚些时候会添加一些测试并发送更改

campoy 于 2016-10-25

🎉23 👍22 ❤10

这是伟大的家伙！ 👍

matiasinsaurralde 于 2016-10-25

@robpike您是否也考虑过我在 #17271 中的替代提案？我想了解为什么认为这个提议更好

rasky 于 2016-10-25

👍3

Go 安装目录和工作区目录的名称相同，即go不是一个好主意，因为：

1）如果用户在主目录中执行tar -xzf go$VERSION.$OS-$ARCH.tar.gz ，则天真的用户很容易损坏/污染工作区

2) 新用户在/usr/local不安装时的默认体验（不想以 root 身份安装）不会顺利，因为这将是流程：
下载 go$VERSION.$OS-$ARCH.tar.gz
tar -xzf go$VERSION.$OS-$ARCH.tar.gz --> 安装在 $HOME/go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something --> 抛出cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

krishnasrinivas 于 2016-10-25

@krishnasrinivas我的理解是，如果GOROOT=$HOME/go ，这个默认值要么不会发生，要么会导致go错误，因为GOROOT和GOPATH不能相同。在这种情况下，如前所述，预计用户有足够的能力设置他们自己的GOPATH 。

mvdan 于 2016-10-25

@mvdan正确，对于不想使用 root 权限进行安装的新用户（因此很有可能在 ~/go 中安装 Go），我们并没有让启动和运行变得更容易，因为他们必须明确将 GOPATH 设置为其他内容。如果默认 GOPATH 是 ~/gopath 或 ~/gocode，则可以轻松修复此问题

对于非 root 安装，如果新用户必须利用默认的 GOPATH=~/go 那么安装文档必须通过明确要求用户使用tar -C选项以便不安装它来稍微复杂一些在~/go

krishnasrinivas 于 2016-10-25

@rasky我认为 #17271 和这个提议是正交的。该提案的解决是一个轻松的胜利，不会将我们推向任何特定方向。我将进一步详细说明这个问题。

adg 于 2016-10-25

我同意@krishnasrinivas。我没有 root 权限，所以我只是解压到 $HOME/go。我也设置了我的 $GOPATH=$HOME/gowork。

joegrasse 于 2016-10-25

@krishnasrinivas @joegrasse没有完美的解决方案。自己设置GOPATH很容易，我希望大多数人都会这样做。这里的问题是我们应该为最新使用 Go 的人做些什么。这些通常不是在自定义位置安装自己的 Go 发行版的人。可以弄清楚如何在自定义位置安装 Go 的人可以弄清楚如何设置GOPATH 。

而不是一类使用预装 Go 发行版的新程序员。我们希望他们能够开始编写 Go 代码。我们不希望第一步是“这就是环境变量。这就是你设置的方式。现在将GOPATH为这个。” 这些步骤与 Go 本身无关。

同样，没有完美的解决方案，但选择一些东西似乎是明智的。

ianlancetaylor 于 2016-10-25

👍9 ❤1

@ianlancetaylor我完全同意应该选择一些东西。我只是相信去解压到 ./go，默认为 $HOME/go，可能不是最好的选择。

joegrasse 于 2016-10-25

由于上述原因， @ianlancetaylor GOPATH=$HOME/gopath 是比 GOPATH=$HOME/go 更好的默认值。

krishnasrinivas 于 2016-10-25

👎5 👍3

我认为当前名称不是问题 - 如果您知道如何为 homedir 下的自定义 go/bin 位置设置 PATH，那么您就知道如何设置 GOPATH。

mccoyst 于 2016-10-25

@joegrasse @krishnasrinivas看看“安装到自定义位置”。

如果您要解压到/usr/local/go以外的任何地方——出于权限或其他原因——也有必要设置 GOROOT，或者从源代码编译。

只要是这种情况，与建议的 $HOME/go 相比，使用 $HOME/gopath 等就没有任何好处。

nathany 于 2016-10-25

👍6

您假设新用户更喜欢从 tar.gz 安装。我可以不
数字，但相信您的回答是基于 Linux 安装的，其中
是第三大最受欢迎的安装目标。

在星期二，2016年10月25日，20点28分克里希纳SRINIVAS [email protected]
写道：

@mvdan https://github.com/mvdan正确，对于不想使用的用户
使用 root 权限进行安装（因此安装的机会很高
进入 ~/go) 我们并没有让启动和运行变得更容易
他们必须明确地将 GOPATH 设置为其他内容。这可以
如果 GOPATH 是 ~/gopath 或 ~/gocode，则很容易修复
对于非root安装，如果新用户必须利用默认
GOPATH=~/go 那么文档必须稍微复杂一些
通过明确要求用户使用 tar -C 选项，以免将其安装在
〜/去
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -255984498，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

davecheney 于 2016-10-25

文档也都需要更新。这可能是大部分工作。

2016 年 10 月 25 日 10:14，Francesc Campoy通知@github.com
写道：

我会这么说，是的。这听起来不像是要完成大量的代码。
我明天就可以开始了。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -255892314，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

adg 于 2016-10-25

我会这么说，是的。这听起来不像是要完成大量的代码。
我明天就可以开始了。

2016 年 10 月 24 日星期一下午 4:05 Brad Fitzpatrick通知@github.com
写道：

@campoy https://github.com/campoy ，你能在 <= 这个星期五之前做吗？
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -255890668，或者静音
线程
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

campoy 于 2016-10-25

如有必要，我可以帮助处理文档。唯一的问题是当前的材料完全依赖于 GOPATH 作为参考点。例如，

“或者，因为您已将$GOPATH/bin到PATH ，只需键入二进制名称：”

或者

“在GOPATH下创建包，mkdir -p $GOPATH/src/github.com/user/hello”

如果不使用 GOPATH 并了解它是什么，除了获取第三方软件包之外，几乎不可能在 Go 中完成任何事情。如果我们可以通过go env报告默认路径，那在文档中很容易引用。

rakyll 于 2016-10-25

也许 $HOME/go/... 可以代替（或 Windows 上的等价物）？

由于您已将$HOME/go/bin到您的 PATH （或$GOPATH/bin如果设置了 GOPATH）...

也许在某些时候文档可以期望个人不仅设置 PATH 环境变量，而且还将 GOPATH 设置为 $HOME/go。即使是多余的，它也为用户以后对 GOPATH 的引用做好了准备。

初始文档可以采用默认值，根本不提及环境变量。

nathany 于 2016-10-25

您假设新用户更喜欢从 tar.gz 安装。我可以不
数字，但相信您的回答是基于 Linux 安装的，其中
是第三大最受欢迎的安装目标。

你是对的，我的观点偏向于 Linux 安装。我可以看到，对于在 /usr/local 中安装 go 的新用户，~/go 可能是比 ~/gopath 更容易识别的目录名

krishnasrinivas 于 2016-10-25

初始文档可以假定默认值而不提及
环境变量呢？

是的，希望所有关于设置 GOPATH 的令人分心的争论都可以移动
安装文档的附录，只是我们为 GOROOT 所做的
目前。

在星期三，2016年10月26日，06:01弥敦道杨曼[email protected]写道：

也许 $HOME/go/... 可以代替（或等效于
视窗）？
由于您已将 $HOME/go/bin 添加到您的 PATH （或 $GOPATH/bin 如果 GOPATH 是
放）...
也许在某些时候，文档可能会期望个人不会
只设置 PATH 环境变量，还要将 GOPATH 设置为 $HOME/go。
尽管是多余的，但它使以后的文档变得清晰。
初始文档可以假设默认值而不是提及环境
变量？
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256142424，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

davecheney 于 2016-10-25

初始文档可以采用默认值，根本不提及环境变量。

SGTM

Go 用户有两种类型：

只是去获取现有包的用户
Go 开发者用户

默认 GOPATH 正在修复第一组的情况。我们仍然可以为面向开发人员的文档保留与 GOPATH 相关的说明。安装根本不必再提及设置 GOPATH 或者我们可以像@davecheney提到的那样有一个附录。

rakyll 于 2016-10-25

👍1

作为一个因为 Go 而不得不重命名 ~/bin/go 的人，我想建议无论默认值如何，如果它已经存在，那么它必须有一个 .dotfile 来表明它真的是 Go 的 ~/go。当 ~/go 不存在时，go 可以创建它，制作 .dotfile，以后运行可以找到它。如果我明确地将 GOPATH 设置为 ~/go 则不需要 .dotfile ，因为没有使用默认值。

RalphCorderoy 于 2016-10-25

点文件存在。它是 $HOME/go 中的 src/ 目录。

2016 年 10 月 26 日，星期三，07:59，RalphCorderoy [email protected]写道：

作为一个因为 Go 而不得不重命名 ~/bin/go 的人，我想建议
无论默认值如何，如果它已经存在，那么它必须有一个
.dotfile 表示它真的是 Go 的 ~/go。当 ~/go 不存在时，
go 可以创建它，制作 .dotfile，以后运行可以找到它。如果我
明确地将 GOPATH 设置为 ~/go 然后不需要 .dotfile ，因为没有
正在使用默认值。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256173981，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

davecheney 于 2016-10-25

CL https://golang.org/cl/32019提到了这个问题。

gopherbot 于 2016-10-25

即使一些程序员不知道环境变量，他们
至少应该熟悉_变量_。我想我们需要
使用某些东西来描述文档中工作区的位置，以及
字符串$GOPATH也可能是它。

2016 年 10 月 26 日 06:24，Jaana Burcu Dogan通知@ github.com
写道：

初始文档可以假设默认值而不是提及环境
变量。
SGTM
Go 用户有两种类型：
只是去获取现有包的用户
Go 开发者用户
默认 GOPATH 正在修复第一组的情况。我们还可以保持
面向开发人员的文档的 GOPATH 相关说明。这
安装根本不必再提及设置 GOPATH 了，否则我们
可以有一个附录作为@davecheney https://github.com/davecheney
提到。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256149104，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

adg 于 2016-10-25

感谢是本意，请看原提议。

实际上，我们现在可以说“go get 会将源下载到一个文件夹
调用，在您的主目录中转到/src/github.com/Foo/Bar”

在星期三，2016年10月26日，06:01弥敦道杨曼[email protected]写道：

也许 $HOME/go/... 可以代替（或等效于
视窗）？
由于您已将 $HOME/go/bin 添加到您的 PATH （或 $GOPATH/bin 如果 GOPATH 是
放）...
也许在某些时候，文档可能会期望个人不会
只设置 PATH 环境变量，还要将 GOPATH 设置为 $HOME/go。
尽管是多余的，但它使以后的文档变得清晰。
初始文档可以假设默认值而不是提及环境
变量？
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256142424，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

davecheney 于 2016-10-25

对于Hacktoberfest的最后一周来说，这将是一个大问题

ChrisMcKenzie 于 2016-10-26

点文件存在。它是 $HOME/go 中的 src/ 目录

“src”是常见的“这是由 Go 创建为默认 GOPATH”点文件的方式。

RalphCorderoy 于 2016-10-26

你试图阻止的事情是什么？

2016 年 10 月 26 日星期三上午 9:20，RalphCorderoy通知@github.com
写道：

点文件存在。它是 $HOME/go 中的 src/ 目录
“src”是一种常见的方式，“这是由默认的GOPATH创建的
去”点文件。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256194536，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

davecheney 于 2016-10-26

$HOME/go 会的。

Windows 用户会怎样？

亚历克斯

alexbrainman 于 2016-10-26

Windows 用户将使用%USERPROFILE%\go ，就像 Docker 在这里所做的一样。

campoy 于 2016-10-26

@davecheney ，我试图阻止我两个小时前说的话： https :

去是一个常用词。我有一个 ~/bin/go。人们玩围棋并且有与围棋有关的源代码。当 ~/go 已经存在时默认使用它只是因为它碰巧包含 src 是粗鲁的。如果 ~/go 不存在，那么 Go 可能会获取名称，创建目录，使用重要的点文件将其标记为 golang，例如基于 golang.org 域名。

无论如何，这就是问题所在，也是一个可能的解决方案。即使解决方案不正确，也不意味着问题不存在。

RalphCorderoy 于 2016-10-26

我投$ HOME/组

谢谢。

prsolucoes 于 2016-10-26

👍1

我们可以使用 GOPATH 默认值作为~/.gosrc吗？

denismakogon 于 2016-10-26

我们可以使用 GOPATH 默认值作为~/.gosrc吗？

这将在 Linux 和 OS X 上默认隐藏，在 Windows 中可见。隐藏 GOPATH 的动机是什么？

ironiridis 于 2016-10-26

关于默认值的讨论发生在一个月前。关于$HOME/go的决定已经完成并正在实施。回到那个话题只会让话题长得难以忍受。

mvdan 于 2016-10-26

👍9

人们玩围棋并且有与围棋有关的源代码。

我并没有真正关注您，但鉴于您已将 GOPATH 设置为
别的东西已经，不会对你有影响。

2016 年 10 月 26 日星期三上午 9:43，RalphCorderoy通知@github.com
写道：

@davecheney https://github.com/davecheney ，我试图阻止我
两小时前说：#17262（评论）
https://github.com/golang/go/issues/17262#issuecomment -256173981
去是一个常用词。我有一个 ~/bin/go。人们玩围棋并拥有源代码
跟玩去吧。当它已经存在时默认使用 ~/go
因为它恰好包含 src 是粗鲁的。如果 ~/go 不存在，那么 Go
可以获取名称，创建目录，将其标记为 golang 的
重要的点文件，例如基于 golang.org 域名。
无论如何，这就是问题所在，也是一个可能的解决方案。即使解决了
不是正确的，这并不意味着问题不存在。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256199766，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

davecheney 于 2016-10-26

嗨@davecheney ，这个问题始于你提出 ~/gocode。随着时间的推移，它变成了 ~/go。 @robpike上面说到“如果 $HOME/go 已经存在，选择那个名字只会是一个问题，这只会让已经安装了 go 并且会理解 GOPATH 的专家感到高兴”。我认为被 golang 笼罩了这么久，你们集体忘记了“go”这个词是多么常见，以及它如何有其他含义，比如棋盘游戏。

此更改针对 Go 的新手，其中一些人可能已经拥有 ~/go 以供非 Go 使用。我建议如果 go 出现，发现 GOPATH 未设置，并且不存在 ~/go 则它可能会创建它，获取名称。但是如果 ~/go 确实存在，那么它应该只在它可以告诉它在早期的 GOPATH-less 调用中创建它时才使用它。我建议创建一个 dotfile 作为这个标志。你说 ~/go/src 将作为那个标志。我的反对意见是 src 本身在程序员中并不少见，即那些可能会安装 Go 的人。一个不寻常的点文件，例如 ~/go/.default-gopath 避免了这种潜在的冲突。

如果他们为 Go 手动创建了 ~/go 并在没有 GOPATH 的情况下运行 go，那么它将不会使用 ~/go 因为缺少点文件。我认为这是可以的，因为通过开始设置他们应该继续的 Go 安装，设置 GOPATH。它们不是目标的简单“安装包，运行 go(1)”案例。

如果这些都不是问题，那就没问题了。但是只要你抱怨你不明白我的意思，我就注定要继续试图解释它。

RalphCorderoy 于 2016-10-27

这就是为什么我最初建议了一条不同的道路，而 Rob 的建议现在正式超出了我的控制范围。

话虽如此，我很高兴选择了 _a_ 路径，因为我认为这是练习的重点。

对于您的担忧，我建议您关注https://go-review.googlesource.com/#/c/32019/ ，其中正在讨论您所关注的问题。

davecheney 于 2016-10-27

@RalphCorderoy ，您担心的是棋盘游戏程序员有一个 ~/go 目录用于棋盘游戏黑客攻击吗？

Rob 和 Russ 是非常反对 dotfiles 的。如果答案涉及点文件（或符号链接），最好说明问题而不是说明答案。

bradfitz 于 2016-10-27

@bradfitz ，是的， ~/go 已经存在于 gogame 玩家，并且进一步存在 ~/go/src 因为他们是程序员 gogame 玩家，否则他们不会玩弄围棋。（我有 ~/chess/src 碰巧。）

adg 的摘要逻辑https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c 看起来不错，我赞成创建 ~/go 如果它不存在，但是test -d ~/go/src如果没有 GOPATH，

如果不是 ~/go，而是更不寻常的东西，比如 Dave 最初的建议，那么就没有关系了。我认为当投票者是足够热衷于关注问题和社交媒体的 Go 程序员时，对当前使用的调查显示 ~/go 非常受欢迎并没有太大帮助。

RalphCorderoy 于 2016-10-27

@RalphCorderoy我认为在 CL 32019 中设计的护理量和双内裤足以给一小群围棋程序员带来的潜在不便，他们_尚未_在 1.8 版之前使用围棋并且_尚未_设置GOPATH _and_ 也开始学习 Go 语言。

go 工具不会删除或破坏它遇到的任何非 go 代码，你只会在_少数_情况下得到一个稍微令人困惑的消息。为了解释这一点，go 工具不会在$GOPATH/src的顶部构建 Go 源代码，因为该代码不在可导入包中。此外，此更改的另一个目标是通过提供下载源的默认位置来更轻松地go get某些代码，因此 _if_ 在~/go/src有游戏的源代码

我认为您担心的情况不太可能发生，并通过上述解释进一步缓解。

davecheney 于 2016-10-27

👍1

（只是反对GOPATH=$HOME一个可能有效的论据）： goimports的性能是否得到解决？我记得关于.goimport_ignore文件的一些事情。否则流行编辑器的性能可能会受到影响。

因此， GOPATH!=$HOME可能是一个无碰撞/无污染的选项，应该是高性能的。

djui 于 2016-10-27

@davecheney在go get我必须清除 ~/go/{bin,src,pkg} 并且粘贴了我在 Internet 上找到的行，这对 Go 来说不是一个很好的介绍。

RalphCorderoy 于 2016-10-27

@RalphCorderoy请理解此更改的目标是让 Go 新用户更容易使用——这不是你——你已经设置了 $GOPATH，因为从 1.1 开始，你_必须_使用 Go 的每个版本。 go-the-game 用户和 _potential_ go-the-programming-language 用户之间的重叠非常小。我不认为会有问题。

davecheney 于 2016-10-27

👍2

@RalphCorderoy您所描述的情况很少见，任何从随机网站运行 shell 命令的人都不应该期望他们的磁盘不会被擦除，更不用说下载并在同名目录中随机播放的一些文件了。（编辑：考虑 Wine 自动创建和修改用户主目录中的.wine 。如果用户在那里有其他东西怎么办？毕竟，“wine”是我们用于特定饮料的术语。）

“围棋”语言和“围棋”棋盘游戏之间的命名冲突当然是众所周知的。文件系统是一个共享资源，冲突是不可避免的。

ironiridis 于 2016-10-27

👍1

@davecheney ，请不要再告诉我这个更改不是为了帮助我，因为我不是 Go 的新用户。甚至在你开始指出之前，我就一直意识到这一点。我也理解你的立场是 len(intersect(existing-~/go, GOPATH-less)) 太小而不能引起关注。

在清理了 ~/go 中的 go-get spew 之后，因为他知道那里通常不存在什么，然后他必须研究以查看命令在 $HOME 下可能还做了什么，以防万一需要清理。

RalphCorderoy 于 2016-10-27

退订

bketelsen 于 2016-10-27

如果我冒犯了你，我很抱歉。不想再通信了
和你一起探讨这个问题。谢谢你。

2016 年 10 月 28 日星期五上午 3:28，RalphCorderoy通知@github.com
写道：

@davecheney https://github.com/davecheney ，请不要告诉我这个
change 不是为了帮助我，因为我不是 Go 的新用户。我有
甚至在你开始指出它之前就一直意识到这一点。我也
了解您的位置是 len(intersect(existing-~/go, GOPATH-less)) 是
太小了，不用担心。
在清理了 ~/go 中的 go-get spew 之后，因为他知道什么
通常不在那里，然后他必须研究看看还有什么
命令可能已在 $HOME 下完成，以防需要更多清理。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/golang/go/issues/17262#issuecomment -256697043，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

davecheney 于 2016-10-27

davecheney，不，不是冒犯。只是没有必要继续覆盖相同的地面。

RalphCorderoy 于 2016-10-27

只是想知道 - 如果未设置$HOME的预期行为是什么？

虽然我从来没有在这样的系统上工作过，但似乎有人出于某种原因修改了他们的默认环境变量，并且应该一致地处理这种边缘情况。

我认为它目前评估$GOPATH='' ；这是否意味着它将使用当前工作目录？

peggyl 于 2016-10-27

使用当前工作目录

我突然想到，这对于没有设置 GOPATH 的新 Go 用户来说可能是最有用的。 go get类似于 wget 等，填充当前目录。在这一点上，他们对 GOPATH 的路径方面不感兴趣，并且很可能希望他们每次尝试使用不同的在线内容时都是不同的，因为他们自己制作的新临时目录会给他们。他们可以获取、运行和轻松删除他们看到引用的不同存储库。

如果未设置 GOPATH：
- 如果只有一两个，但不是全部 ~/{bin,pkg,src} 存在：
- 他们必须设置 GOPATH，pkg 是不寻常的
- 否则全部或不存在：
- 确保它们都存在
- GOPATH=$(密码)

RalphCorderoy 于 2016-10-27

我对此有复杂的感觉，但我的普遍看法（作为设置$GOPATH ）是go get行为应该是“确定性的”，并且总是在$GOPATH下安装东西 –一致且有据可查的目的地。

尽管我不受此更改的影响，但感觉奇怪的是go get会根据发出命令时的工作目录将内容下载到不同的位置。我知道这就是wget 、 npm install和其他工具所做的，但这感觉就像偏离了一致的$GOPATH值的想法（这就是我的方式诠释了这次变革的精神）。

如果这超出了本问题的范围，我建议在$HOME实际未设置时简单地退出并输出错误。

peggyl 于 2016-10-27

👍3

我教过 5 位来自第三世界国家的 Java 世界的新程序员。他们肯定对 GOPATH 感到困惑。哎呀，当我在 Go 1 发布之前重新开始时，我也是如此。我个人使用“$HOME/gopath”，但我建议“go get”命令将他们指向一个关于如何为他们的操作系统创建 go 路径的明确的 go 博客。这就是我们所需要的。 “go get”命令的一些指导不是规范..而是一篇该死的简单博客文章！

einthusan 于 2016-10-29

显然我的意思是当没有设置 GOPATH 时。只需更新当前显示的错误消息。采用率已经存在了.. 只需要一点帮助，而不是新来者正在做的当前 google it up 方法。

einthusan 于 2016-10-29

@einthusan我觉得它在https://golang.org/doc/code.html#GOPATH上有很好的记录，但我不知道有多少开始使用 Go 的人实际上阅读了这个页面。

peggyl 于 2016-10-29

👍2

抱歉发垃圾邮件.. 做了一些谷歌搜索之后.. 我认为“go get”应该只是提示用户说“没有设置 GOPATH...你想使用当前工作目录作为你的临时 GOPATH 吗？” （是/否）

einthusan 于 2016-10-29

👎4

@einthusan ，没有 cmd/go 进行交互式提示的先例。

bradfitz 于 2016-10-29

如果新的默认 GOPATH 是 $HOME/go。人们不会期望这个https://hub.docker.com/_/golang/采取相同的行为吗？

cescoferraro 于 2016-11-01

@cescoferraro这是该图像维护者的问题。尽管它被标记为“官方”，但该项目与 Go 无关。

davecheney 于 2016-11-01

👍1

回答/回应我自己关于 unset $HOME ：

在当前的实现中（上面链接了 CL），如果未设置$HOME ，则$GOPATH默认为"" ： https :

我相信这种极端情况是不太可能的，因为$HOME总是在正常的登录会话中设置，这对于大多数 Go 程序员来说很可能是这种情况。虽然我个人 _like_ 要明确澄清行为，但似乎没有“副作用”（例如在工作目录中安装东西）。如果我错了纠正我。 :)

peggyl 于 2016-11-01

如果这是为了让第一次开始使用 Go 的人更容易，让它像当前路径一样：

GOPATH=$(pwd)

设置export GOPATH=$(pwd)可以轻松切换项目

jinmatt 于 2016-11-02

👎5 👍1

我针对此更改建议的行为：

环境变量

如果设置了GOPATH则工具的行为与往常一样
否则，我们检查HOME （ home为的Plan9， USERPROFILE适用于Windows）环境变量。
- 如果该环境变量未设置，则GOPATH也不会设置：这意味着“go get”将失败并显示cannot download, $GOPATH not set.

> unset GOPATH
> unset HOME
> go env GOPATH

否则GOPATH将被设置为$HOME/go ( $home/go , %USERPROFILE%\go )。

> unset GOPATH
> go env GOPATH
/Users/campoy/go

GOPATH 创建

目前，如果$GOPATH不存在，它会在我们执行go get import/path 。这不会改变。

唯一的变化是，如果$GOPATH未在用户环境中设置（即 echo $GOPATH 不显示值），则会执行额外检查以确保默认值是可接受的：

如果未设置 GOPATH 且未创建默认值：命令将失败

> unset GOPATH
> unset HOME
> go get github.com/golang/example/hello
package github.com/golang/example/hello: cannot download, $GOPATH not set. For more details see: 'go help gopath'
👎

如果默认的$GOPATH不存在，则会显示一个警告，说明该目录已创建，指向go help gopath以获取更多信息。

> unset GOPATH
> go get github.com/golang/example/hello
warning: GOPATH is not set, creating directory /Users/campoy/go. See 'go help gopath' for more information
👍

如果默认$GOPATH存在：
- 它不是目录：命令将失败（就像以前一样）

> unset GOPATH
> touch ~/go
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not a directory
👎

并且它是一个空目录或一个目录，该目录具有名为src的子目录，命令将成功（没有警告）

> unset GOPATH
> mkdir ~/go
> go get github.com/golang/example/hello
👍

> unset GOPATH
> mkdir -p ~/go/src
> touch ~/go/others
> go get github.com/golang/example/hello
👍

它是一个非空目录，没有名为src的子目录，命令将失败

> unset GOPATH
> mkdir ~/go
> touch ~/go/others
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not empty, and no 'src' was found
👎

因此，每当使用默认GOPATH创建目录时，只会包含一个新警告。

campoy 于 2016-11-02

👍6

@campoy行为建议看起来很棒。

但是作为一个高级用户，我想知道我们中有多少人每天认真地使用$HOME/go作为GOPATH ？我什至在想也许应该有一个 go 命令来设置GOPATH类似于在 python 工作目录上启动虚拟环境。

由于我从事多个项目，我通常会做这样的事情：

$ cd foo-app
$ export GOPATH=$(pwd)

# switching to another app
$ cd ../foobar-app
$ export GOPATH=$(pwd)

jinmatt 于 2016-11-02

@jinmatt
此更改仅修改未设置 GOPATH 的行为，这是更改的范围。
社区已经就 $HOME/go 达成了协议。

如果您不喜欢$HOME/go ，只需将GOPATH设置

campoy 于 2016-11-02

谢谢你的设计草图。

由于我们现在已经确定 GOPATH 只会在 'go get' 期间创建，所以我们只在给出 -v 标志时打印消息，与 'go get -v' 行为的其余部分一致。
如果创建了目录，消息最多应该是

# 创建 GOPATH=/users/campoy/go; 参见“去帮助 gopath”

这不是警告：警告是不好的。另一方面，如果创建失败，那么您可能想要打印

go: creating GOPATH=/users/campoy/go: %v

无论 GOPATH 是推断还是显式设置，都可以打印这两条消息。

关于空目录和具有 src 子目录的启发式太复杂了。更糟糕的是，它们正在解决假设问题，而假设问题很难设计。最好有更简单、更可预测的行为。首先，我认为没有任何规则是有道理的，直到有实际问题的具体例子。人们将有时间在测试版和发布候选期间报告问题。让我们设置 GOPATH=$HOME/go （如果设置了 $HOME）。

编辑：假装 Github 降价并没有完全搞砸。

rsc 于 2016-11-02

👍2

@campoy关于src/目录，当设置了 GOPATH 但不存在 src 目录时， go get的当前行为是什么？是否有充分的理由不创建它？

如果 $HOME/go/src 是在第一次 go get 时创建的（或者 $GOPATH/src 如果设置了该环境变量），解释起来似乎更简单

nathany 于 2016-11-02

今天，当 GOPATH 被设置时，必要的目录会根据需要无条件地创建。

rsc 于 2016-11-03

👍5

CL https://golang.org/cl/33356提到了这个问题。

gopherbot 于 2016-11-17

CL https://golang.org/cl/33730提到了这个问题。

gopherbot 于 2016-11-30

Go: cmd/go: 假设 GOPATH=$HOME/go 如果没有设置

最有用的评论

所有137条评论

环境变量

GOPATH 创建

相关问题