有关$ GOPATH的一些问题

有关$ GOPATH的一些问题

（2018年第二季度：
请注意，对于 vgo项目
，

GOPATH

可能最终不赞成使用基于项目的工作流。这样可以避免

GOPATH

两年前我在下面提出的基于手动项目的建议）

使用Go 1.11（2018年8月），

GOPATH

可以是可选的，带有modules
。

VSCode越来越支持它：

• vspre-go / issue 1532
• “ Visual Studio Code中的Go模块支持 ”

---

2016年6月：您不必 仅
依赖一个

GOPATH

（即一个工作区）。

我的全部

GOPATH

内容包括：

• 一个全球性的路径（所有公用事业喜欢

  goimports

  ），

  github.com/smartystreets/goconvey

  …），在

  $HOME/go

  例如，
• 本地路径（我当前的项目），在我的地方

  src

  ，

  pkg

  并且

  bin

  会。

这是两条路径：

export GOPATH=/path/to/myproject:$HOME/go

为我的所有项目都拥有一个$ GOPATH目录是不安全的，因此所有必需的第三方库都安装在同一个lib目录中，并且每当我编译项目时，它都将使用所需的库。

在实践中这不好吗？为什么？

我不喜欢这种做法，因为不同的项目可能需要同一个库的不同 版本 。
这就是为什么

GOPATH

每个项目都有一个，我的构建脚本（随项目版本化）为我设置的原因。

当我克隆我的go项目时，我：

• 将我

  GOPATH

  设置为该go项目（本地路径，将安装该项目所需的第三方库，并将其移至

  vendor

  文件夹中），
• 与该路径进行符号链接

  <myproject>/src/<myproject> -> ../..

  ，因为

  GOPATH

  手段go希望找到

  myproject

  in 的来源

  src/<apackage>

  。

该组织：

• 保持兼容

  go get

  ，
• 确保默认情况下，将我需要的所有特定依赖项安装在我的项目文件夹中，而不是在global中存在的大量全局库/实用程序中丢失

  GOPATH

  。

我有：

myproject   mysource.go   apackage     othersource.go   src     myproject -> ../..     vendor        third-party packages

在Windows上，典型的构建脚本为：

λ more b.bat@echo offsetlocal EnableDelayedExpansionif not defined GOROOT (        echo Environment variable GOROOT must be defined, with %%GOROOT%%bingo.exe        exit /b 1)set PATH=C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbemset PATH=%PATH%;%GOROOT%/binset GOPATH=%~dp0;%HOME%/goset prjname=%GOPATH:~0,-1%for %%i in ("%prjname%") do set "prjname=%%~ni"rem echo prjname='%prjname%'if not exist src (        mkdir src)if not exist src%prjname% (        mklink /J src%prjname% %GOPATH%)pushd %~dp0cd src%prjname%rem cdgo installpopdendlocal

克隆我的go项目的任何人都只需键入“

b

”。