Как управлять GOPATH для нескольких каталогов проектов
Исходя из опыта Java и Grails (и написав миллионы строк C 30 лет назад), я не могу понять, как можно использовать go с фиксированным gopath на окнах.
установка го создает эту структуру
c:\users\me\go\scr
\pkg
\bin
Поскольку вам захочется иметь много проектов go, кажется, что они должны быть смешаны вместе в одной и той же директории src/kpg/bin, загрязняя друг друга. например
/src/project1/hello.go
/project2/hello.go
/pkg/xx
/bin/hello.exe
Какой hello.go будет работать hello.exe?
Если я не пропустил что-то фундаментальное, это кажется сумасшедшим - все совершенно разные проекты должны иметь один и тот же пакет и папки bin. Это означает, что вы не знаете, какие версии каких пакетов и какие exe-файлы принадлежат какому проекту, и, вероятно, существует множество возможностей для конфликтов. Я ожидал бы /src, /pkg и / bin для каждого отдельного приложения go (например, java или grails или даже C), и путь go полностью избыточен, он может быть относительно корня текущего проекта (как в grails).
Чтобы все работало, для работы нам нужно использовать другое направление, например
d:\work\project3
\project4
\package5
\go_utility6
\go_utility7
Так что теперь у нас есть 6 отдельных каталогов, в которых живут программы. Невозможно изменить путь каждый раз, когда вы переключаетесь на работу над другим проектом. Я предполагаю, что другой вариант - добавить 6 путей к GOPATH. Предположительно, все 7 go проектов пишут в один и тот же pkg и bin dir, что будет катастрофой.
Есть ли надежное решение этой ситуации (по крайней мере, для Windows)?
Если нам нужно добавить PATH в GOPATH для каждого проекта, какой должна быть файловая структура для каждого проекта?
Например, uner xxx\go_utility6, который является автономным приложением go командной строки, какой должна быть структура? где-то там должен быть src dir? нужен ли этому директору гопат, чтобы указать на него? ему нужен собственный pkg, или он должен использовать каталог c:\users\me\pkg?
2 ответа
Для этого я использую vg, он заботится о сохранении отдельных путей GOPATH для каждого проекта и автоматически переключается, когда вы cd проект.
Ваш пример "который hello.exe" должен использоваться честно, не имеет особого смысла. Два инструмента с одинаковым именем? Даже если оба, скажем, API, ваши девопы будут счастливее с более значимыми именами.
Папка bin используется для сторонних инструментов, которые вы устанавливаете, поэтому вам не нужно устанавливать двоичные файлы проекта. За исключением того, что они являются инструментами, но тогда имя должно снова иметь значение.
Вы можете получить больше информации о структуре проекта здесь: https://golang.org/doc/code.html
Поскольку go 1.8 поддерживает папку vendor ниже папок проекта, существует возможность нарушить исходную структуру. (поставщики imho до 1.8 не обслуживались, да, это было безумие)
Возможно, вы захотите использовать инструмент наподобие direnv, который поддержит ваше желание изменять GOPATH для каждого проекта. https://github.com/direnv/direnv
Он также имеет некоторую встроенную функцию для добавления текущего пути к GOPATH. https://github.com/direnv/direnv/blob/master/stdlib.sh#L355:1
Например, GoLang также поддерживает обработку нескольких GOPATH и GOPATH для каждого проекта. Так что direnv также должен работать правильно.
В моей компании у нас есть папка "go" рядом с другими нашими проектами. Под go / src находятся наши проекты. Пока проблем нет, поскольку поставщики находятся в папках поставщиков проектов и зафиксированы.
На данный момент лучший менеджер зависимостей, который я бы порекомендовал для go: https://github.com/golang/dep
Я надеюсь, что вклад поможет.
В Go 1.11 были представлены модули Go. Вы можете использовать модули Go для создания проектов Go за пределами каталога GOPATH.
Вот пример того, как настроить проект с помощью GoModules.