go module

После перехода на Go modules упростилась работа с форками, так как в Go нет относительных импортов из коробки.

Go modules же позволяют подменить через replace любую из завимостей ― удобно, когда нужно пропатчить даже не прямую зависимость, а зависимость зависимости, и после этого как-то тестить.

Какой-то не очень знающий у тебя «знающий». Модули вкрутили чтобы гораздо сильнее была возможность управлять зависимостями, ну и от gopath чтобы можно было отвязаться ибо он слишком прост в своей задумке. Представь, ты пишешь свой проект и добавляешь модули А и В. Оба они имеют зависимость от С, но А зависит от С версии х1, а В от С версии х3. Лучше сам почитай про бенефиты го модулей, чем слушать некомпетентные мнения.

В смысле с форками ? Т.е. есть 2 одинаковых github.com/z123/y456 так что ли ?

Можно (наконец-то) заменить любую зависимость на форк без правки всех импортов этой зависимости.

В смысле можно заменить любую зависимость на форк без правки всех импортов этой зависимости.

Т.е. ln -s не катит ?

ну если на то пошло, то можно было просто origin добавить, но все-таки новый способ гораздо проще, удобнее и прямее.

Представь, ты пишешь свой проект и добавляешь модули А и В. Оба они имеют зависимость от С, но А зависит от С версии х1, а В от С версии х3.

Извините это с трудом себе представляю. А можно по реальнее пример ? К примеру у меня есть gorilla mux, я его буду юзать одной версии, зачем две то ?

Проходил мимо, на Go не пишу, но пример привести могу.

Есть, например, фреймворк у тебя. Фреймворк требует версию одной из своих зависимостей 1.0.0. Кроме этого фреймворка ты подключаешь какую-нибудь небольшую библиотеку для какой-нибудь небольшой, но очень важной мелочи, и библиотека эта тоже подключается к той самой зависимости, но уже версии 2.0.0. Приходится выбирать.

Чтобы выбирать не приходилось и вводятся такие костыли.

ln -s не катит

слишком толсто

чего только не делают лишь бы git submodule не использовать, php composer, go module