Обновление Июнь 2015: первая поддержка для поставщиков вступает в Go 1.5!
См c/10923/:
Когда GO15VENDOREXPERIMENT=1 находится в окружающей среде, это CL изменяет разрешение на импорт путей в соответствии с Go 1.5 поставщика предложения:
- Если есть исходный каталог
d/vendor, а затем, при компиляции исходного файла в поддереве, корневом в d, import "p" понимается как import "d/vendor/p", если это существует.
- Когда есть несколько возможных разрешений, выигрывает самый конкретный (самый длинный) путь.
- Короткая форма всегда должна использоваться: путь импорта не может содержать «
/vendor/» явно.
- Импорт комментариев игнорируется в пакетах поставщиков.
март 2015 Обновления: команда идти думает об определении системы управления зависимостью идти внедрённый язык: дебаты in this thread.
Мы считаем, что пришло время, чтобы начать решения vendoring проблемы зависимостей &, особенно перед слишком много противоречащих друг другу инструментов возникают и фрагмент передового опыта в экосистеме Go, излишне усложнять оснастки. Было бы неплохо, если бы сообщество могло сходиться стандартным образом к поставщику.
Наше предложение заключается в том, что проект Go,
- официально рекомендует vendoring в «internal» каталог с импортом переписыванием (не
GOPATH модификации) в качестве канонического пути приколоть зависимости.
- определяет общий формат файла конфигурации для зависимостей & vendoring
- не вносит никаких изменений кода в
cmd/go в Go 1.5. Внешние инструменты, такие как «godep» или «nut», будут реализованы 1) и 2). Мы можем переоценить, включая такой инструмент в Go 1.6+.
Одним из возможных Недостатком godep является то, что вы больше не можете использовать «идти строить» или «идти тест» напрямую.
Вам необходимо перед этими командами godep (или введите godep save).
Альтернатива glide, которая по-прежнему совместима с классическими командами go.
- Управления конкретных проектов GOPATHs
- Простота управление зависимостью
- Поддержки версионности пакеты
- Поддержки сглаживание пакетов (например, для работы с GitHub вилком)
- Удалить необходимость "vendoring" или munging импортных заявлений
- Работа со всеми инструментами go
В целом, статья «Know your guarantees, Go edition» интересно:
Это также осознанный выбор, где авторы Go решили не реализовывать функцию, когда они чувствовали, что компромиссы были не хорошо.
Одна из причин низкого уровня, по которой они сделали этот выбор, заключается в том, чтобы избежать медленной компиляции и раздутых двоичных файлов (которые являются двумя сторонами одной и той же монеты).
Помните, упаковки зависят от других пакетов. Таким образом, Foo может зависеть от Bar 2.1. Foo также может зависеть от Baz, который, в свою очередь, зависит от Bar 1.9, а также от дерева. Таким образом, это означало бы компиляцию и связывание нескольких копий почти идентичного кода.
В зависимости от нескольких версий одного и того же пакета также подразумевается, что какая версия вызывается, в результате чего беспорядок зависимостей проникает в ваш исходный код.
Это приводит нас к высокоуровневым рассуждениям на платформе Go, накладывающими на эту функцию: у них не было логического решения, которое они считали приемлемым. Дело не в том, что они не понимают проблему; это то, что на данный момент нет никакого решения, которое им нравится. Поэтому они не выбирают никакой функции над регрессивным.