Какая хорошая передовая практика с рабочими пространствами Go?

Я просто изучаю Go и читаю через существующий код, чтобы узнать "как это делают другие". При этом использование рабочего пространства go, особенно в том, что касается зависимостей проекта, кажется, повсеместно.

Что (или есть) общая практика использования одного или нескольких рабочих пространств Go (т.е. определения $GOPATH) при работе над различными проектами Go? Должен ли я ожидать наличия единого рабочего пространства Go, похожего на центральный репозиторий кода для всех моих проектов, или явно разбить его и настроить $GOPATH, когда я буду работать над каждым из этих проектов (вроде как python virtualenv)?

Ответ 1

Я использовал несколько GOPATH - десятки. Переключение между проектами и поддержание зависимостей было намного сложнее, потому что извлечение полезного обновления в одном рабочем пространстве требовало, чтобы я делал это в других, и иногда я забывал и царапал себе голову, задаваясь вопросом, почему эта зависимость работает в одном проекте но не другой. Фиаско.

Теперь у меня есть только один GOPATH, и я фактически поместил все мои проекты dev - Go or not - внутри него. Благодаря одному центральному рабочему пространству я могу сохранить каждый проект в собственном репозитории git (src/<whatever>) и использовать разветвление git для управления зависимостями, когда это необходимо (на практике, очень редко).

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

Ответ 2

Мне кажется, что проще всего иметь один $GOPATH для каждого проекта, таким образом вы можете иметь разные версии одного и того же пакета для разных проектов и обновлять пакеты по мере необходимости.

При использовании центрального репозитория сложно обновить пакет, поскольку при этом вы можете нарушить несвязанный проект (если обновление пакета имеет нарушения или новые ошибки).

Ответ 3

Использование одного GOPATH во всех ваших проектах очень удобно, но я считаю, что это относится только к моим личным проектам.

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

Итак, что-то вроде:

~/code/my-project
- src
  - github.com
    + dependency-one
    + dependency-two
    - my-org
      - my-project
        * main.go
        + package-one
        + package-two
- pkg
- bin

Установив GOPATH в ~/code/my-project, он использует подмодули зависимости-один и зависимые-два git внутри этого проекта вместо использования глобальных зависимостей.

Ответ 4

Попробуйте envirius (универсальный менеджер виртуальных сред). Он позволяет скомпилировать любую версию go и создать на ней любое количество окружений. $GOPATH/$GOROOT зависят от каждой конкретной среды.

Кроме того, он позволяет создавать среды со смешанными языками (например, python и go в одной среде).

Ответ 5

Если вы просто установили GOPATH в $HOME/go или аналогичные и начали работать, все работает из коробки и действительно легко.

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

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

Но в целом, если вы обнаружите, что занимаетесь большей работой, это часто происходит потому, что вы решили сделать все сложнее.

У меня есть то, что должно приближаться к 100 проектам, которые я накопил за последние четыре года. Я почти всегда работаю в GOPATH, который $HOME/go на моих компьютерах.

Ответ 6

В моей компании я создал Virtualgo, чтобы упростить управление несколькими GOPATH. Несколько преимуществ перед обработкой вручную:

Автоматическое переключение на правильный GOPATH при cd в проект.
Он хорошо интегрируется с инструментами для продажи.
Он также устанавливает новый GOBIN на вашем пути, поэтому вы можете использовать исполняемые файлы, установленные там.
Он по-прежнему имеет исходный GOPATH в качестве резервной копии. Если пакет не найден в рабочем пространстве проекта, он будет искать основной GOPATH.

Ответ 7

Одна рабочая область + godep лучше всего для меня.

Ответ 8

Просто используйте GoSwitch. Экономит много времени и здравомыслия. Добавьте script в корень каждого из ваших проектов и отправьте его. Он сделает этот проект вашим гопатом, а также добавит/удалит точную папку bin этого проекта в путь. https://github.com/buffonomics/goswitch