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

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

  

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

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

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

go
31 голос | спросил Pete 27 Jpm1000000pmTue, 27 Jan 2015 22:57:40 +030015 2015, 22:57:40

2 ответа


12

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

Вы упомянули go install, но также go test (и хороший инструмент go test -cover) не будет работать go get, который позволяет вам загружать удаленный код, будет записывать все в GOPATH, поэтому вам нужно будет скопировать все.

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

ответил iccananea 28 Jpm1000000pmWed, 28 Jan 2015 19:37:31 +030015 2015, 19:37:31
9

(отказ от ответственности: мне нравится разрабатывать такие вещи, но я новичок в 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, затем символизируя проект)
ответил Kos 15 FebruaryEurope/MoscowbSun, 15 Feb 2015 14:25:35 +0300000000pmSun, 15 Feb 2015 14:25:35 +030015 2015, 14:25:35

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132