Подтвердить что ты не робот

Как сделать "go get" в определенном теге репозитория github

Я пытаюсь скомпилировать базу данных InfluxDB (версия v0.8.8) с помощью go get github.com/influxdb/influxdb

Но это тянет главную ветвь, и мне нужен тег v0.8.8.

Я попытался сделать: go get github.com/influxdb/influxdb/releases/tag/v0.8.8, но это не позволяет не найти.

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

Проблема с использованием последнего подхода заключается в том, что когда я пытаюсь вытащить зависимости с помощью go get -u -f ./..., он пытается найти их в главной ветки, а некоторые из них не существуют на главной ветке...

TL; DR: выполнить go get в определенном теге github и вывести правильные зависимости.

4b9b3361

Ответ 1

Это невозможно с помощью инструмента go get. Вместо этого вам нужно использовать сторонний инструмент управления пакетами go или создать свои собственные вилки для пакетов, которыми вы хотите управлять более детально.

Говорил с парнем, который работает в Google, и он признал эту проблему/требование, он сказал, что вендинг, который использовал его команда, был громоздким, и они, вероятно, скоро решат его с помощью официальных инструментов.

Прочитайте больше:

Вендорство в Go 1.6

Вендор был выпущен из экспериментальной версии 1.6 (после того, как этот пост был изначально написан), что облегчает процесс использования определенных тегов/версий пакетов с использованием сторонних инструментов. go get все еще не имеет функции для извлечения определенных тегов или версий.

Подробнее о том, как работает вендоринг: понимание и использование папки вендора

Модули в Go 1.11

Go 1.11 выпустил экспериментальные функции, называемые модулями для улучшения управления зависимостями, они надеются выпустить его как стабильный в Go 1.12: Информация о модулях в Go 1.11

Ответ 2

У меня был успех с этим:

  • Запустите команду get без тега - она ​​должна клонировать главную ветвь.
  • Перейдите в каталог клонирования и проверьте тег или ветку, которые вы хотите.
  • Запустите команду get get еще раз, она должна обработать команду на проверенной ветке.

Ответ 3

go mod доступен сейчас.

Для тех, кому нужно создать двоичный файл определенного тега, вот мой способ:

mkdir temp
cd temp
go mod init .
go get -d -v github.com/nsqio/[email protected]
mkdir bin
go build -o bin/nsqd.exe github.com/nsqio/nsq/apps/nsqd

Объяснение:

  • Приведенный выше код извлекает NSQ v1.1.0 и nsqd.
  • go mod init. создает файл go.mod в текущем каталоге, что позволяет использовать go get с revision/tags. (см. эту ссылку)
  • -d означает "только загрузка", если вы хотите прямую установку, опустите этот флаг и команды сборки ниже этой строки.
  • -v означает "быть многословным".
  • Приведенный выше код для Windows. Если вы используете Linux, замените bin/nsqd.exe на bin/nsqd.

Загруженный модуль хранится в папке %GOPATH%\pkg\mod. Если вы не хотите загрязнять свой каталог GOPATH, создайте новый и установите его в GOPATH.

Ответ 4

У меня есть (несколько хакерский, но рабочий) подход для решения этой проблемы, по крайней мере для репозиториев git: Поскольку go get'ed пакеты являются нормальными репозиториями управления версиями, можно проверить теги, используя обычные инструменты git (можно использовать git из командной строки, я использую Atlassian SourceTree).

Чтобы поделиться моей конфигурацией пакета с моими товарищами по команде, я сделал репозиторий git из моего GOPATH. Затем я добавил все пакеты (по крайней мере, те, которые я хотел бы использовать таким образом) для этого репо в качестве подмодуля git. Это требует, чтобы вы перемещали существующие папки репо и добавляли их как подмодуль git, чтобы не путать git. Этот процесс несколько утомительный, но оказался полезным:

Теперь я могу совершить и нажать на мой GOPATH-repo каждый раз, когда я использую новый пакет go. Когда мои товарищи по команде вытаскивают из этого репо и выпускают обновление подмодуля git (или просто обновляют через SoureTree, что делает это автоматически), их версия пакета проверяется на том же теге, что и мой.

Конечно, это работает только для пакетов под git контролем источника...