Организация многофайлового проекта Go

Question

Примечание: этот вопрос относится к этому , но два года - это очень много времени в истории Go.

Каков стандартный способ организации проекта Go во время разработки?

Мой проект представляет собой один пакет mypack, поэтому я полагаю, что все файлы .go помещены в каталог mypack.

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

Как мне это организовать?Нужно ли делать go install mypack каждый раз, когда я хочу попробовать?

Answer 1

Я бы порекомендовал просмотреть эту страницу на Как написать код Go

Он описывает как структурировать ваш проект в удобном для go build виде, а также как писать тесты.Тесты не должны быть cmd с использованием пакета main.Они могут быть просто именованными функциями TestX как часть каждого пакета, и тогда go test обнаружит их.

Структура, предложенная в этой ссылке в вашем вопросе, немного устарела, теперь с выпуском Go 1.Вам больше не нужно помещать каталог pkg в src.Единственные 3 директории, связанные со спецификацией - это 3 в корне вашей GOPATH: bin, pkg, src.Под src вы можете просто поместить свой проект mypack, а под ним - все ваши файлы .go, включая mypack_test.go

go build, которые затем будут встроены в корневой уровень pkg и bin.

Так что ваш GOPATH может выглядеть так:

~/projects/
    bin/
    pkg/
    src/
      mypack/
        foo.go
        bar.go
        mypack_test.go

export GOPATH=$HOME/projects

$ go build mypack
$ go test mypack

Обновление: начиная с> = Go 1.11, модуль В настоящее время система является стандартной частью инструментов, а концепция GOPATH близка к устареванию.

Answer 2

jdi имеет правильную информацию относительно использования GOPATH. Я хотел бы добавить, что если вы хотите иметь двоичный файл, возможно, вы захотите добавить еще один уровень в каталоги.

~/projects/src/
    myproj/
        mypack/
            lib.go
            lib_test.go
            ...
        myapp/
            main.go

при запуске go build myproj/mypack создаст пакет mypack вместе с его зависимостями запуск go build myproj/myapp создаст двоичный файл myapp вместе с его зависимостями, который, вероятно, включает библиотеку mypack.

Answer 3

Я изучил несколько проектов Go, и есть немало вариантов. Вы можете сказать, кто приходит из C, а кто из Java, так как первый из них создает дамп практически всего в корневом каталоге проектов в пакете main, а последний обычно помещает все в каталог src. Ни то, ни другое не является оптимальным. У каждого есть последствия, потому что они влияют на пути импорта и то, как другие могут их использовать.

Чтобы получить наилучшие результаты, я разработал следующий подход.

myproj/
  main/
    mypack.go
  mypack.go

Где mypack.go равно package mypack, а main/mypack.go (очевидно) package main.

Если вам нужны дополнительные файлы поддержки, у вас есть два варианта. Либо храните их все в корневом каталоге, либо поместите файлы поддержки private в подкаталог lib. Э.Г.

myproj/
  main/
    mypack.go
  myextras/
    someextra.go
  mypack.go
  mysupport.go

Или

myproj.org/
  lib/
    mysupport.go
    myextras/
      someextra.go
  main/
    mypack.go
  mypage.go

Помещайте файлы в каталог lib, только если они не предназначены для импорта другим проектом. Другими словами, если они являются закрытыми файлами поддержки. В этом и заключается идея lib - отделять общедоступные и частные интерфейсы.

Выполнение этих действий даст вам хороший путь импорта myproj.org/mypack для повторного использования кода в других проектах. Если вы используете lib, то внутренние файлы поддержки будут иметь путь импорта, который указывает на это, myproj.org/lib/mysupport.

При создании проекта используйте main/mypack, например. go build main/mypack. Если у вас есть более одного исполняемого файла, вы также можете отделить его под main, не создавая отдельные проекты. например main/myfoo/myfoo.go и main/mybar/mybar.go.

Answer 4

Мне очень полезно понять, как организовать код на Голанге в этой главе http://www.golang -book.com / 11 книги, написанной Калебом Докси

Answer 5

Похоже, стандартного способа организации проектов Go не существует, но https://golang.org/doc/code.html определяет наилучшую практику для большинства проектов. Ответ jdi хорош, но если вы используете github или bitbucket и у вас есть дополнительные библиотеки, вы должны создать следующую структуру:

~/projects/
bin/
pkg/
src/
  github.com/
    username/
        mypack/
            foo.go
            bar.go
            mypack_test.go
        mylib/
            utillib.go
            utillib_test.go

Делая это таким образом, вы можете создать отдельный репозиторий для mylib, который может использоваться для других проектов и может быть получен с помощью команды "go get". Ваш проект mypack может импортировать вашу библиотеку, используя "github.com/username/mylib". Для получения дополнительной информации:

http://www.alexvictorchan.com/2014/11/06/go-project-structure/

Answer 6

Храните файлы в одном каталоге и используйте package main во всех файлах.

myproj/
   your-program/
      main.go
      lib.go

Затем запустите:

~/myproj/your-program$ go build && ./your-program

Answer 7

Давайте рассмотрим, как команда go get repository_remote_url управляет структурой проекта в $GOPATH.Если мы сделаем go get github.com/gohugoio/hugo, он будет клонировать репозиторий в

$ GOPATH / src / repository_remote / user_name / project_name

---

$ GOPATH / src / github.com / gohugoio / hugo

Это хороший способ создать начальный путь проекта .Теперь давайте исследуем, какие типы проектов существуют и как организованы их внутренние структуры.Все проекты golang в сообществе можно отнести к категории

• Libraries (без исполняемых двоичных файлов)
• Single Project (содержит только 1 исполняемый двоичный файл)
• Tooling Projects (содержит несколько исполняемых двоичных файлов)

---

Обычно файлы проекта golang могут быть упакованы в соответствии с любыми принципами проектирования , такими как DDD , POD

Большинство доступных проектов go следуют этому Дизайн, ориентированный на пакеты

Дизайн, ориентированный на пакеты поощряют разработчика сохранять только реализациювнутри своих собственных пакетов, кроме пакета /internal, эти пакеты не могут взаимодействовать друг с другом

---

Библиотеки

• Такие проекты, как драйверы баз данных , qt можно поместить в эту категорию.
• Некоторые библиотеки, такие как color , now , следуют плоской структуре без каких-либо других пакетов.
• Большинство этих библиотечных проектов манаges пакет с именем internal .
• /internal package в основном используется для скрытия реализации от других проектов.
• Не имеет исполняемых двоичных файлов, поэтому нет файловсодержит main func .

---

 ~/$GOPATH/
    bin/
    pkg/
    src/
      repository_remote/
        user_name/
            project_name/
              internal/
              other_pkg/

---

Отдельный проект

• Такие проекты, как hugo , etcd имеет single основной функционал на корневом уровне и
• Цель - сгенерировать один двоичный файл

Проекты инструментов

• Такие проекты, как kubernetes , go-ethereum имеет множественный основной функционал, организованный в пакете под названием cmd
• cmd/ Пакет управляет количеством двоичных файлов (инструментов), которые мы хотим построить

---

 ~/$GOPATH/
    bin/
    pkg/
    src/
      repository_remote/
        user_name/
            project_name/
              cmd/
                binary_one/
                   main.go
                binary_two/
                   main.go
                binary_three/
                   main.go
              other_pkg/