модули go несколько основных методов

У меня есть проект с множеством основных методов. При запуске go build program1/main1.go, который имеет другой набор зависимостей, чем program2/main2.go, мой первый go build, кажется, изменяет мой go.mod файл и удаляет зависимости, которые, по его мнению, не нужны. И все же main2 потребуются эти зависимости.

Я пробовал использовать go build ..., но это также создало другой набор зависимостей. В частности, кажется, что все //indirect зависимости удаляются, что приводит к сбою программы program2.

Есть ли способ запустить go build или go run без обновления файла go.mod? Используя go build -mod=readonly program1/main1.go, он сообщает мне, что он не работает, потому что необходимо обновить зависимости ..


person Dylan Meeus    schedule 11.02.2019    source источник
comment
Если две вещи не имеют одинаковые зависимости, и каждая должна иметь свой собственный go.mod. Go.mod содержит the зависимости, а не только некоторые (читайте несвязанные, старые и оставшиеся после копирования) зависимости.   -  person Volker    schedule 11.02.2019


Ответы (2)


Я полагаю, вы ищете подмодули. См. эту прогулку.

TL; DR: вам понадобится отдельный go.mod в cmd директории каждого вашего инструмента, и вы можете использовать директиву replace, чтобы указать зависимости этих инструментов на ваш локальный модуль.

Эта проблема Go и другие связанные с ней проблемы предполагают, что выяснение "единственного правильного пути" делать это по-прежнему WIP, хотя я думаю, что ваш вариант использования достаточно прост.

person Eli Bendersky    schedule 11.02.2019
comment
Да, в конце концов я так и сделал :) Спасибо! - person Dylan Meeus; 14.02.2019

Использование подмодулей - это способ вложить несколько проектов модулей Go, которые вы можете редактировать.

Но Go 1.18 может включать понятие рабочее пространство Go, что означает, что вам больше не нужны подмодули: один проект Go может включать несколько модулей, которые вы можете редактировать.

См. golang/go проблему 45713: предложение: cmd/go: добавить режим рабочей области и его проектный документ.

Background

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

Обычно команда go распознает единственный модуль main, который может редактировать пользователь.
Другие модули доступны только для чтения и загружаются из кеша модуля.

Директива go mod replace является исключением: она позволяет пользователям заменять разрешенную версию модуля рабочей версией на диске.
Но работа с директивой replace часто может быть неудобной: у каждого разработчика модуля могут быть рабочие версии в разных местах на диске, поэтому наличие директивы в файле, который должен распространяться с модулем, не подходит для всех случаев использования.

Proposal

Это предложение описывает новый режим рабочего пространства в команде go для редактирования нескольких модулей.

Наличие файла go.work в рабочем каталоге или содержащем его каталоге переводит команду go в режим рабочей области.
Файл go.work определяет набор локальных модулей которые составляют рабочее пространство. При вызове в режиме рабочей области команда go всегда будет выбирать эти модули и согласованный набор зависимостей.

Основные модули: модуль, в котором работает пользователь.
До этого предложения это единственный модуль, содержащий каталог, в котором вызывается команда go. Этот модуль используется в качестве отправной точки при запуске MVS.
В этом предложении предлагается разрешить использование нескольких основных модулей.

См., Например, CL 334934 (CL = список изменений)

[dev.cmdgo] cmd/go: add the workspace mode

Это изменение добавляет схему реализации режима рабочего пространства.

Команда go теперь найдет go.work файлы и прочитает их, чтобы определить, какие модули находятся в рабочей области.
Затем она поместит эти модули в корень рабочей области при создании списка сборки.
Она поддерживает сборку , запуск, тестирование и перечисление в рабочих областях.

Вы можете инициировать многомодульный проект с помощью go mod initwork

Опять же, это произойдет не раньше, чем Go 1.18 (первый квартал 2022 года), и, вероятно, будет включен в Go 1.19 (третий квартал 2022 года).

person VonC    schedule 17.07.2021