Беглый взгляд на Go Workspaces в Go 1.18

[shortcircuit]

Я правильно понимаю, что при запуске через go run ... отдельной утилиты с микроскопическим go.mod, лежащей в монорепе с гигантскими go.mod, всё равно скачаются все-все-все зависимости всех go.mod, которые есть в воркспейсе?

[Bozaro]

Да. Именно так. Микроскопическая утилита запустится с обобщенным go.mod.

С моей точки зрения, в контексте монорепы Go Workspaces бесполезны, так как по факту мы просто получаем распределённый go.mod.

[shortcircuit]

А есть какой-то способ сказать, что "вот этот конкретный go.mod не относится к воркспейсу"?

[Bozaro]

В go.work явно перечисляются используемые go.mod-ы.
Если директория с go.mod там не указана, то GoLang будет её игнорировать и запустить из неё без ключа -workfile=off не получится. Будет ошибка вида:

go: no modules were found in the current workspace; see 'go help work'

[gohrytt]

Звучит как какая-то бесполезная х***я. Простите.

[THQSql]

Я думаю это не для прода, а для удобства разработки. Иногда это пригождается для каких-то внутренних зависимостей, которые ещё не обновлены, например на новую спецификацию и ты им подсовываешь свежак.

[newprim]

Я конечно джун на Go, но за 5 месяцев работы ни разу вообще не пришлось даже зайти в go.mod, не то что что-то самому там писать. IDE и go mod tidy вроде справлялись сами неплохо.

В общем, лично мне что-то не хватило понимания, что поменялось и зачем это вообще надо :)

[stanlyzoolo]

Аналогично. Качующий список зависимостей, с первого взгляда :)

[tendium]

Чую, это будет одна из самых непонятых фич go. На go пишу лет 5 уже, и — признаюсь — так и не осилил, для чего нужен этот go.work. До этого читал в оригинале, теперь тут. Хотя, может проблема во мне, а не в go.work.

[Bozaro]

Я изначально то же ждал от go.work совершенно другого поведения: он меня интересовал в контексте работы с несколькими go.mod в рамках монорепозитория.

Но он сделан для другого:

• решение проблемы с IDE, которые используют gopls для интеграции, например VS Code (в этом случае при работе с несколькими go.mod надо открывать по одному экземпляру IDE на каждый go.mod);

• решение проблемы работы с несколькими связанным go.mod в разных репозиториях.

Если для Вас эти сценарии не актуальны, то эта фича действительно выглядит предельно странно.

[stanlyzoolo]

в VS Code можно создавать свои воркспейсы, которые замечательно работают

[Borz]

можно не пользоаться монорепой. Иметь десяток репозитариев и собирать нужный комплект реп локально "под себя", не заморачиваясь при этом с replace. А при выкладке в VCS, уже CI сервер проверит всю связку - что у остальных не отвалилось ничего от твоих правок