Должен ли я совершать Godeps/_workspace или достаточно Godeps.json?

Question

Я пишу проект в Go для развертывания на heroku, управляя зависимостями с godep.

Когда я godep save, я получаю как в Godeps.json файл со списком своих зависимостей с версиями и _workspace/ каталога с источником для всех зависимостей скопированных. Я предпочел бы не совершать _workspace, все, что код уже на GitHub в другом месте. Кажется, Godeps.json имеет всю необходимую информацию для go get зависимых от версии зависимых зависимостей от времени heroku buildpack.

Severalsources рекомендовать полный каталог Godeps/, но другие предлагают его might not be necessary.

The godep документы не очень помогают:

Это сохранит список зависимостей в файл Godeps/Godeps.json и скопировать исходный код в Godeps/_workspace. Прочитайте его содержимое и убедитесь, что он выглядит разумным. Затем зафиксируйте файл для управления версиями.

Is Godeps.json ?

Answer 1

Официальный ответ:

От GitHub вопрос #131:

Предполагаемое использование godep является зависимостей поставщика и зафиксировать каталог _workspace для контроля версий. См. Документ заявки @kr, связанный в # 123 (предложение: http://goo.gl/RpYs8e). Как обсуждалось в этом предложении, у бога состоялся режим (-copy = false), который поддерживал не экспорт зависимостей. Я предполагаю, что из-за этого может возникнуть неоднозначный язык в Readme. Этот режим был удален, как описано в № 123.

Вот и godep автор говорил о своем проекте и идеях позади - Vendoring and Import Path Rewriting

Личное мнение:

Я не думаю, что это правильный способ сделать это.

Совершение поставщика LIBS кажется неуклюжим, но у него есть свои преимущества:

• Вы не опираясь на внешние услуги (GitHub, и т.д.). У GitHub нет сбоев, может быть, у вас есть какая-то ужасная политика компании, которая мешает вам использовать ее, возможно, репозиторий исчезает или история переписывается, возможно, вы находитесь за брандмауэром (сервер постановки/сборки) и т. Д.
• Каждый раз, когда есть обновления к вашим папкам вы получаете хороший разброс изменений. Это помогает при обновлении до более новой версии или просто отслеживании изменений, если вы используете экранный код, который используется.

В конце концов, вам нужно взвесить все за и против. Лично я сжимаю каждый раз, когда мне приходится комментировать код поставщика, но в моих проектах Go я делаю. По крайней мере на данный момент.

Также компании, такие как Google и Facebook, в основном хранят все в одном репозитории и включают код поставщика (или, как я уже слышал).

Интересная статья по теме: Go Package Management

Answer 2

Для создания обратных зависимостей вам понадобится файл json, как показано в update.go.
Так что файл должен быть версией.

Но тогда godep would fill the content of godep/_workspace, что означает, что это «сгенерированный» контент: вам не нужно его выпускать.

Answer 3

Просто добавьте файл Godeps.json в репо и _workspace в список .gitignore :).

Хотя ваш код должен быть полностью включен в ваше репо, зависимости нужно как-то просто ссылаться (godep.json, package.json, git subodule ... вы выбираете) и не более того. Та же самая тактика применяется к npm, bower, apt и всем другим менеджерам пакетов.

Ваше репо - ваши вещи + ссылки на вендоров поставщиков (конечно, когда это возможно, вы не можете ссылаться на zp-файл sourceforge).

Как сказал @VonC, мы не хотим выпускать версии вендоров.