Переход от GOPATH к Go модулям - PullRequest
       13

Переход от GOPATH к Go модулям

0 голосов
/ 10 апреля 2020

Это не вопрос, требующий быстрого решения, а стратегического мышления, на которое, я думаю, нет простого ответа.

  • При подходе GOPATH, пока я помещаю свои модули в GOPATH в нужных местах (например, $GOPATH/src/mycompany/mylib/lib.go), go будет их подбирать.
  • С Go 1.14, каким-то образом, даже если я поместил свои модули в GOPATH в нужных местах, go get или go build все еще не могут их поднять. (Я до сих пор не понимаю, почему, поскольку я только что спешно приземлился на Go 1.14.)

Теперь ,

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

Я хочу перейти на Go модульный подход, но есть вещи, которые я до сих пор не понял, особенно как преодолеть препятствие «вещи в нужном месте» - у меня есть 6 или 7 взаимосвязанных пакетов, распределенных по различным репозиториям git git пользователей или организаций, некоторые из них являются публичными c, а некоторые - частными. И вот где моя проблема.

С подходом GOPATH я просто символически связываю их (из их индивидуального репо git) в подходящие места под GOPATH. Я использую symlink вместо go get, чтобы поместить их туда, потому что во время активной разработки все 6 или 7 взаимосвязанных пакетов движутся вперед вместе , потому что они взаимосвязаны. Я не могу выпустить их один за другим, но я должен отправить их всех вперед (надеюсь, что такой подход не очень необычен). Подход GOPATH очень терпим с таким подходом. Мне даже не нужно делать git push, чтобы проверить их вместе. Только после того, как все тестирование нормально, я делаю git push.

Теперь, с модульным подходом Go, я могу сделать то же самое? Могу ли я проверить их вместе еще до git push? Я боюсь, что мне нужно сделать наоборот, сначала протолкнуть непроверенный код через прокси. golang .org, прежде чем я смогу начать их совместное тестирование. Надеюсь, я ошибаюсь.

Один из способов достижения вышеизложенного - использовать «заменить директивы» :

Если вы хотите иметь несколько взаимосвязанных модулей на вашем локальном диске, которые вы хотите редактировать одновременно, а затем заменить директивы - это один из подходов.

Однако, поскольку это взлом файла go.mod с replace ссылками в соответствии с моим локальным расположением диска, например, replace example.com/me/goodbye => ..../some/other/path/of/goodbye, такой взлом не является слишком дружелюбный к людям, которые хотят просто использовать мой модуль, если go.mod переведен в git, но мне нужно, чтобы он был передан. Это кажется мне дилеммой (или постоянной борьбой).

Какова ваша стратегия, если вы решаете ситуацию, подобную описанной выше?

...