Имеет ли исходный код для проекта Go за пределами GOPATH плохую идею

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

$ GOPATH / SRC / github.com / НазваниеКомпании / имя_проекта

который также является корнем git-репозитория

Стандартный рекомендуемый формат пути кажется немного странным, особенно если мы работаем над многоязыковым проектом, например, основанным на Go бэкендом rest / 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

Вам будет хорошо идти.