некоторые вопросы относительно $ GOPATH

Я новый разработчик Golang и мне интересно, почему$GOPATH переменная окружения должна быть установлена ​​в корне моего проекта.

Если я работаю над несколькими проектами одновременно, мне нужно каждый раз переустанавливать$GOPATH переменная окружения, указывающая на другое местоположение.

В моей настройке у меня есть$GOPATH установлен в/Users/Projects/go/lib, который является общим каталогом для всех моих проектов Голанга.

Просто чтобы уточнить: данные проектов размещены в/Users/Projects/go/<Project Name>

Если так или иначе все$GOPATH используется для (насколько я знаю) для установки сторонних библиотек, не безопасно ли иметь один$GOPATH каталог для всех моих проектов, поэтому все необходимые сторонние библиотеки устанавливаются в один и тот же каталог lib, и всякий раз, когда я компилирую проекты, он просто использует необходимые библиотеки.

Это плохо на практике? Зачем?

 user53981019 июн. 2016 г., 15:57
В принципеGOPATH относится к «рабочему пространству Go», как сказал Шиклоши, так что вы можете найтиЧто является хорошим передовым опытом с рабочими пространствами Go? чтобы было интересно читать. У него разные ответы с разными причинами этих ответов. Лично я использую схему с одним рабочим пространством, но, очевидно, она может варьироваться в зависимости от требований проекта.
 ameyCU19 июн. 2016 г., 07:41
Вы можете поместить свои проекты в один каталог. Там не должно быть никаких проблем.
 Shikloshi19 июн. 2016 г., 07:42
Это многое прояснит -golang.org/doc/code.html Обратите внимание, что $ GOPATH считается рабочим пространством go, все проекты go должны быть помещены в подкаталог src. Существует множество ресурсов, объясняющих использование $ GOPATH.

Ответы на вопрос(1)

Решение Вопроса


Обратите внимание, что спроект VGO, GOPATH может оказаться устаревшим в пользу проектного рабочего процесса. Это позволит избежать ручного проектногоGOPATH Я предлагал ниже, два года назад)

С Go 1.11 (август 2018),GOPATH может быть необязательным, с модулями.

Все больше и больше поддерживается с VSCode:

vscode-go / выпуск 1532"Поддержка модулей Go в Visual Studio Code"

Июнь 2016: вам не нужно полагаться натолько одинGOPATH (т.е.одно рабочее пространство).

Мой полныйGOPATH включает в себя:

глобальный путь (для всех утилит, таких какgoimports),github.com/smartystreets/goconvey, ...), в$HOME/go например,локальный путь (для моего текущего проекта), где мой местныйsrc, pkg а такжеbin будет.

Это два пути:

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

Разве не безопасно иметь один каталог $ GOPATH для всех моих проектов, поэтому все необходимые сторонние библиотеки устанавливаются в один и тот же каталог lib, и всякий раз, когда я компилирую проекты, он просто использует необходимые библиотеки.

Это плохо на практике? Зачем?

Мне не нравится эта практика, поскольку разные проекты могут требовать разныхверсия из той же библиотеки.
Вот почему у меня есть одинGOPATH для каждого проекта, который мне устанавливает мой скрипт сборки (в соответствии с проектом).

Когда я клонирую свой проект go, я:

установить мойGOPATH к этому проекту (локальный путь, где сторонние библиотеки, которые мне нужны для этого проекта, будут установлены и перемещены вvendor папка),сделать символическую ссылку на этот путь<myproject>/src/<myproject> -> ../.., посколькуGOPATH значит иди ожидает найти источникиmyproject вsrc/<apackage>.

Эта организация:

остается совместимым с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».

 VonC12 дек. 2018 г., 16:11
@ tomriddle_1234 Я согласен. И вы можете комбинировать это с вашим собственным модулем URL репозитория:thumbai.app а такжеgithub.com/thumbai/thumbai
 VonC09 окт. 2018 г., 09:15
@minghua Но все, что устарело с модулями Go сейчас (1.11+):github.com/golang/go/wiki/Modules
 VonC09 окт. 2018 г., 09:05
@minghua mklink / J myproject ../ ..
 minghua09 окт. 2018 г., 08:38
Потрясающие! Этот символ ссылкиmyproject -> ../.. это именно то, что я был озадачен, чтобы выяснить, как обрабатывать свой собственный код, который вы не хотите помещать в общий каталог, который должен содержать только сторонний код. Я думал об использовании двух частей в GOPATH для вашей и сторонней, но это сталкивается с большим количеством проблем. Один вопрос, однако, как вы это делаете на MS-Windows?
 tomriddle_123412 дек. 2018 г., 16:00
gopath - беспорядок, особенно если вы из страны, где golang.org и github.com иногда блокируются, каждый раз, когда вы используете сторонний инструмент, обходите сеть, например, gopm, чтобы получить go lib, схему управления версиями git сломается, так как эти инструменты изменяют пути, это означает, что вы никогда не обновите библиотеку должным образом, единственный вариант - переустановить каждую обновленную библиотеку. С новым модом больше не нужно менять путь, как счастливый npm.

Ваш ответ на вопрос