Неправильна ідея наявності вихідного коду для проекту Go за межами GOPATH

Я працюю над новим проектом, використовуючи Go, і ми всі нові для Go. Ми слідуємо за стандартною структурою каталогу go і маємо під собою весь код

$ GOPATH / src / github.com / назва компанії / ім'я проекту

який також є коренем сховища git

Стандартний рекомендований макет шляху здається дещо дивним, особливо якщо ми працюємо над багатомовним проектом, наприклад, на базі відпочинку на базі відпочинку / http, а також на передній частині html / javascript. У такому випадку я, мабуть, хотів би, щоб моя структура проекту виглядала так:

/
  doc/
  src/
    server/
      main.go
      module1/
        module.go
    client/
      index.html
  Makefile

Але чи дійсно потрібно розмістити код всередині GOPATH?

Як спробу я створив невелику програму, де вихідний код знаходився поза GOPATH. Я міг легко розділити проект на пакети, щоб mainпакет міг посилатись на fooпакет у foo/папці, використовуючи import "./foo".

Наскільки я бачу, це дві речі, що мене відключають:

• Інший код не може імпортувати цей код. Це не проблема, оскільки ми будуємо послугу спеціально для компанії.
• Я не можу використовувати його go installдля встановлення. Це теж не проблема. У конвеєрі встановлюється інструмент.

Однак це дозволяє серверу збірки не мати його робочої області, розташованої всередині GOPATH

Чи не рекомендується такий підхід? Якщо так, то чому так?

Чи є інші негативні побічні ефекти, ніж два, які я перерахував?

Майте на увазі, що це приватний проект для компанії, а не публічний відкритий код.

Від'єднання фактичного проекту від GOPATH видається заманливим, але слід бути обережним у порушенні правил, коли ти перебуваєш на сцені Шу.

Вам не потрібно використовувати GOPATH, але тоді ви пропускаєте всі приємні інструменти, які ви отримуєте з goкоманди. Всі вони очікують, що код буде в стандартній ієрархії GOPATH.

Ви згадали go install, але також go test(і приємний go test -coverінструмент покриття) не працюватиме go get, що дозволяє завантажувати віддалений код, запише все в GOPATH, тому вам потрібно буде копіювати речі.

Звичайно, ви можете замінити все це на make / scons / cmake / що завгодно, і все буде зроблено, і це, ймовірно, буде працювати для вашого оточення, але його додаткова робота, яку можна виконати goінструментом.

(відмова від відповідальності: мені подобається конструювати такі речі, але я новачок у Go, я не пробував цього на практиці)

Ідея: чому б не обидва?

Є два полярні варіанти, якщо ви враховуєте посилання:

(A) Код у src, що посилається на робочу область

/
  doc/
  src/
    server/
      projectname/
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname -> ../../../src/server/projectname
      github.com/
        someone/
          library/
    bin/
    pkg/
  Makefile

(B) Код у робочій області, що посилається на src

/
  doc/
  src/
    server/
      projectname -> ../../go_workspace/src/companyname/projectname
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname/
      github.com/
        someone/
          somelib/
    bin/
    pkg/
  Makefile

Я схиляюся до "А", тому що:

• всі ваші джерела живуть фізично близько,
• projectname Ви можете легко мати власне репо, або Ви можете мати одне репо для всього проекту,
• ви можете зберегти цілий go_workspaceнеперевершений і ініціалізувати його за допомогою кроку make (використовуючи godepпотім посилання на проект)

Оновлення 2019 року

Вам більше не потрібно зберігати проект GOPATH.

Просто помістіть його в будь-який каталог поза GOPATH. Потім введіть:

go mod init github.com/youruser/yourproject

Вам буде добре піти.