有关$ GOPATH的一些问题 [英] some questions regarding $GOPATH

问题描述

我是一名新的golang开发人员，我想知道为什么需要在项目的根目录下设置$GOPATH环境变量.

如果我同时从事多个项目，则每次都需要重新设置$GOPATH环境变量以指向不同的位置.

在我的设置中，我将$GOPATH设置为/Users/Projects/go/lib.这是我所有golang项目的通用目录.​​

请澄清一下:项目数据放置在

中

如果(据我所知)所有$GOPATH都用于安装第三方库，那么为我所有的项目都拥有一个$GOPATH目录是不安全的，因此所有必需的第三方库都安装在同一个lib目录中，并且每当我在这些项目上进行编译时，它都将使用所需的库.

这真的不好吗?为什么?

解决方案

(2018年第二季度:
请注意，使用 vgo项目 ，GOPATH可能最终因支持基于项目的工作流程.这样可以避免两年前我在下面提出的基于项目的手动GOPATH)

在Go 1.11(2018年8月)中， GOPATH可以是可选的，其中模块 .

VSCode越来越支持它:

• vscode-go/issue 1532
• "在以下语言中支持Go模块Visual Studio代码"

---

2016年6月:您不必仅依靠 一个GOPATH(即一个工作区).

我的完整GOPATH包括:

• 全局路径(对于所有实用程序，例如goimports)， github.com/smartystreets/goconvey ，.. )，例如在$HOME/go中，
• 本地路径(对于我当前的项目)，我的本地src，pkg和bin将在其中.

这是两条路径:

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

为我的所有项目提供一个$ GOPATH目录并不安全，因此所有必需的第三方库都安装在同一lib目录中，并且每当我在这些项目上进行编译时，它都将使用所需的lib.

这真的不好吗?为什么?

我不喜欢这种做法，因为不同的项目可能需要同一个库的不同的版本.
这就是为什么每个项目只有一个GOPATH，我的构建脚本(随项目版本化)为我设置的原因.

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

• 将我的GOPATH设置为该go项目(本地路径，该项目需要的第三方库将安装到该本地路径，并移动到vendor文件夹中)，
• 对该路径<myproject>/src/<myproject> -> ../..进行符号链接，因为GOPATH表示go希望在src/<apackage>中找到myproject的来源.

该组织:

• 与go get保持兼容，
• 确保默认情况下，我需要的所有特定依赖项都安装在我的项目文件夹中，而不会因全局GOPATH中存在的大量全局库/实用程序而丢失.

我有:

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

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

λ more b.bat
@echo off
setlocal EnableDelayedExpansion
if not defined GOROOT (
        echo Environment variable GOROOT must be defined, with %%GOROOT%%\bin\go.exe
        exit /b 1
)

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
set PATH=%PATH%;%GOROOT%/bin
set GOPATH=%~dp0;%HOME%/go

set 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 %~dp0
cd src\%prjname%
rem cd
go install
popd
endlocal

克隆我的go项目的任何人都只需键入"b".

I'm a new golang developer and I wonder why $GOPATH environment variable is needed to be set at the root of my project.

If I'm working on several projects at the same time, I need to each time re-set the $GOPATH environment variable to point to a different location.

In my setup, I have $GOPATH set to /Users/Projects/go/lib. which is a generic directory for all of my golang projects.

Just to clarify: the projects data is placed in /Users/Projects/go/<Project Name>

If anyhow all $GOPATH is used for (as far as I know) is to install 3rd party libraries, isn't it safe to have one $GOPATH directory for all my projects, so all the required 3rd party libraries are installed in the same lib directory, and whenever I compile on of the projects it just uses the libs it requires.

Is this bad in practice? Why?

解决方案

(Q2 2018:
Note that with the vgo project, GOPATH might end up being deprecated in favor of a project-based workflow. That would avoid the manual project-based GOPATH I was proposing below, two years ago)

With Go 1.11 (August 2018), GOPATH can be optional, with modules.

It is more and more supported with VSCode:

• vscode-go/issue 1532
• "Go modules support in Visual Studio Code"

---

June 2016: You don't have to rely on only one GOPATH (ie one workspace).

My full GOPATH includes:

• a global path (for all utilities like goimports), github.com/smartystreets/goconvey, ...), in $HOME/go for instance,
• a local path (for my current project), where my local src, pkg and bin will be.

That is two paths:

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

Isn't it safe to have one $GOPATH directory for all my projects, so all the required 3rd party libraries are installed in the same lib directory, and whenever I compile on of the projects it just uses the libs it requires.

Is this bad in practice? Why?

I don't like that practice, as different projects could require different version of the same library.
That is why I have one GOPATH per project, that my build script (versioned with the project) sets for me.

When I clone a go project of mine, I:

• set my GOPATH to that go project (local path, where the third-party libraries I need for that project will be installed, and moved to a vendor folder),
• make a symlink to that path <myproject>/src/<myproject> -> ../.., since GOPATH means go expects to find the sources of myproject in src/<apackage>.

That organization:

• remains compatible with go get,
• ensure any specific dependencies I need are installed by default in my project folder instead of being lost within the mass of global libraries/utilities present in the global GOPATH.

I have:

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

On Windows, a typical build script would be:

λ more b.bat
@echo off
setlocal EnableDelayedExpansion
if not defined GOROOT (
        echo Environment variable GOROOT must be defined, with %%GOROOT%%\bin\go.exe
        exit /b 1
)

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
set PATH=%PATH%;%GOROOT%/bin
set GOPATH=%~dp0;%HOME%/go

set 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 %~dp0
cd src\%prjname%
rem cd
go install
popd
endlocal

Anyone cloning my go project would simply type 'b'.

这篇关于有关$ GOPATH的一些问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！