Пакет Golang не найден [дубликат]

Обновление в мае 2013 года: официальная документация находится в разделе « Организация кода »

Код Go должен храниться внутри рабочей области. Рабочее пространство представляет собой иерархию каталогов с тремя директориями в своем корне:

• src содержит исходные файлы Go, организованные в пакеты (один пакет для каталога),
• pkg содержит объекты пакета, а
• bin содержит исполняемые команды.

go tool создает исходные пакеты и устанавливает полученные двоичные файлы в каталоги pkg и bin.

Подкаталог src обычно содержит несколько репозиториев управления версиями (например, для Git или Mercurial), которые отслеживают разработку одного или нескольких исходных пакетов.

bin/
    streak                         # command executable
    todo                           # command executable
pkg/
    linux_amd64/
        code.google.com/p/goauth2/
            oauth.a                # package object
        github.com/nf/todo/
            task.a                 # package object
src/
    code.google.com/p/goauth2/
        .hg/                       # mercurial repository metadata
        oauth/
            oauth.go               # package source
            oauth_test.go          # test source

---

Обновление Июль 2014: см. « Структурирование приложений в Go » из Бен Джонсон

Это статья включает следующие советы:

Отделите свой бинарный файл от вашего приложения

, объединяющий файл main.go, и моя логика приложения в том же пакете имеет два следствия:

• Это делает мое приложение непригодным для использования в качестве библиотеки.
[g1 2] У меня может быть только одно бинарное приложение.

Лучший способ найти это - просто использовать в моем проекте каталог «cmd», где каждый из его подкаталогов

camlistore/
  cmd/
    camget/
      main.go
    cammount/
      main.go
    camput/
      main.go
    camtool/
      main.go

Разработка с использованием библиотеки

Перенос файла main.go из вашего корня позволяет вам создавать приложение из перспектива библиотеки. Бинарный файл приложения - это просто клиент библиотеки вашего приложения.

Иногда вам может потребоваться, чтобы пользователи взаимодействовали несколькими способами, поэтому вы создаете несколько двоичных файлов. Например, если у вас есть пакет «adder», который позволяет пользователям добавлять номера вместе, вы можете захотеть выпустить версию командной строки, а также веб-версию. Вы можете легко сделать это, организовав свой проект следующим образом:

adder/
  adder.go
  cmd/
    adder/
      main.go
    adder-server/
      main.go

Пользователи могут установить бинарные файлы приложений «сумматора» с помощью «go get» с помощью многоточия:

$ go get github.com/benbjohnson/adder/...

И у вас есть у пользователя «adder» и «adder-server»

Не сходите с ума subpackages

Обычно типы моего проекта очень взаимосвязаны, поэтому он лучше подходит для удобства использования и API. Эти типы также могут использовать вызовы, не поддерживаемые между ними, что делает API небольшим и понятным.

1. Связанные с группой типы и код вместе в каждом файле. Если ваши типы и функции хорошо организованы, я обнаружил, что файлы, как правило, составляют от 200 до 500 SLOC. Это может показаться много, но мне легко ориентироваться. 1000 SLOC обычно является моим верхним пределом для одного файла.
2. Упорядочить наиболее важный тип в верхней части файла и добавить типы в уменьшающемся значении в нижней части файла.

Примечание: эта последняя практика не всегда хороша:

]

Извините, я просто не могу согласиться с этой практикой. Разделение типа на файлы помогает управлять кодом, читабельности, материнствам, тестируемости. Это может также обеспечить единую ответственность и следовать принципу открытого / закрытого ... Правило не допускать круговой зависимости состоит в том, чтобы заставить нас иметь четкую структуру пакетов.

---

(Альтернатива Февраль 2013 г., только в отношении src). Вы можете найти классический макет, представленный в « макета кода GitHub »:

Приложение и обе библиотеки живут на Github, каждый в своем собственном репозитории. $GOPATH - это корень проекта - каждый из ваших репозиториев Github будет проверен несколькими папками ниже $GOPATH.

Схема вашего кода будет выглядеть так:

$GOPATH/
    src/
        github.com/
            jmcvetta/
                useless/
                    .git/
                    useless.go
                    useless_test.go
                    README.md
                uselessd/
                    .git/
                    uselessd.go
                    uselessd_test.go
                    README.md

Каждая папка в папке src/github.com/jmcvetta/ является корнем отдельного git checkout.

Это привлекло некоторые критические замечания, хотя на этой странице reddit :

Я настоятельно рекомендую не структурировать репо, как вы , он сломается «go get», что является одной из самых полезных вещей о Go. Гораздо лучше написать свой код для людей, которые знают Go, поскольку они, скорее всего, будут их компиляцией. И для людей, которые этого не делают, они, по крайней мере, почувствуют язык.

Поместите основной пакет в корень репо. У вас есть активы в подкаталоге (чтобы все было аккуратно). Храните мясо кода в субпакете (в случае, если кто-то захочет повторно использовать его вне вашего двоичного файла). Включите скрипт установки в корень репо, чтобы его было легко найти.

Это все еще только двухэтапный процесс для загрузки, сборки, установки и настройки .:

• "go get <your repo path>": загружает и устанавливает код go, с поддиретом для активов
• $GOPATH/<your repo path>/setup.sh: распределяет активы в нужном месте и устанавливает службу