Golang подключить второй файл
Обновлено: 06.07.2024
Примечание: этот вопрос относится к этот, но два года это очень большой срок в истории.
каков стандартный способ организации проекта Go во время разработки ?
мой проект-это единый пакет mypack , Так что я думаю, что я положил все .перейти файлы в .
но тогда я хотел бы проверить его во время разработки, поэтому мне нужен хотя бы файл, объявляющий main пакета, так что я могу сделать go run trypack.go
как мне это организовать ? Мне нужно сделать go install mypack каждый раз, когда я хочу попробовать ?
Я бы рекомендовал просмотреть эту страницу на Как написать код Go
документы, как структурировать ваш проект в go build удобный способ, а также Как писать тесты. Тесты не должны быть cmd с помощью . Они могут быть просто названными функциями TestX как часть каждого пакета, а затем go test откроет их.
структура, предложенная в этой ссылке в вашем вопросе, немного устарела, теперь с выпуском Go 1. Вам больше не нужно
jdi имеет правильную информацию, касающуюся использования GOPATH . Я бы добавил, что если вы намерены иметь двоичный файл, а также вы можете добавить один дополнительный уровень в каталоги.
под управлением go build myproj/mypack построить mypack пакет вместе с его зависимостями работает go build myproj/myapp построить myapp двоичный вместе с его зависимостями, которые, вероятно, включают в себя mypack библиотека.
я изучил ряд проектов Go, и есть довольно много вариаций. Вы можете как бы сказать, кто приходит из C, а кто из Java, так как бывший дамп почти все в корневом каталоге проектов в A main пакет, и последние, как правило, положить все в
храните файлы в одном каталоге и используйте package main во всех файлах.
выполнить:
это хороший способ создать свой начальный путь проекта. Теперь давайте исследователь, что такое типы проектов там и как организованы их внутренние структуры. Все проекты golang в сообществе могут быть классифицированы в разделе
- Libraries (нет исполняемых двоичных файлов)
- Single Project (содержит только 1 исполняемый двоичный файл)
- Tooling Projects (содержит несколько исполняемых файлов)
вообще файлы проекта golang можно упаковать под какие-то принципы дизайна например DDD, POD
большинство доступных проектов go следует за этим Пакет Ориентированный Дизайн
Пакет Ориентированный Дизайн поощряйте разработчика сохранять реализацию только внутри своих собственных пакетов, кроме /internal пакет эти пакеты не могут общаться друг с другом
Этот пост демонстрирует разработку простого пакета Go внутри модуля и знакомит с инструментом go, стандартным способом получения, сборки и установки модулей, пакетов и команд Go.
Примечание. В этом посте предполагается, что вы используете Go 1.13 или новее, а переменная среды GO111MODULE не установлена. Если вы ищете старую версию этого поста, предшествующую модулям, она находится здесь.
Организация кода
Программы Go организованы в пакеты. Пакет - это набор исходных файлов в одном каталоге, которые скомпилированы вместе. Функции, типы, переменные и константы, определенные в одном исходном файле, видны всем другим исходным файлам в том же пакете.
Репозиторий содержит один или несколько модулей. Модуль - это набор связанных пакетов Go, которые выпускаются вместе. Репозиторий Go обычно содержит только один модуль, расположенный в корне репозитория. Файл с именем go.mod объявляет путь к модулю: префикс пути импорта для всех пакетов в модуле. Модуль содержит пакеты в каталоге, содержащем его файл go.mod, а также подкаталоги этого каталога до следующего подкаталога, содержащего другой файл go.mod (если есть).
Обратите внимание, что вам не нужно публиковать свой код в удаленном репозитории перед его сборкой. Модуль может быть определен локально без принадлежности к репозиторию. Тем не менее, это хорошая привычка организовывать свой код так, как будто вы когда-нибудь его опубликуете.
Ваша первая программа
Первым оператором в исходном файле Go должно быть имя пакета. Исполняемые команды всегда должны использовать пакет main.
Затем создайте внутри этого каталога файл с именем hello.go, содержащий следующий код Go:
Теперь вы можете собрать и установить эту программу с помощью инструмента go:
Эта команда создает команду hello, создавая исполняемый двоичный файл. Затем он устанавливает этот двоичный файл как $HOME/go/bin/hello (или, в Windows, %USERPROFILE%\go\bin\hello.exe).
Каталог установки управляется переменными среды GOPATH и GOBIN. Если установлен GOBIN, в этот каталог устанавливаются двоичные файлы. Если установлен GOPATH, двоичные файлы устанавливаются в подкаталог bin первого каталога в списке GOPATH. В противном случае двоичные файлы устанавливаются в подкаталог bin GOPATH по умолчанию ($HOME/go или %USERPROFILE%\go).
Вы можете использовать команду go env для переносимой установки значения по умолчанию для переменной среды для будущих команд go:
Чтобы отключить переменную, ранее установленную с помощью go env -w, используйте go env -u:
Для удобства команды go принимают пути относительно рабочего каталога и по умолчанию используют пакет в текущем рабочем каталоге, если не указан другой путь. Итак, в нашем рабочем каталоге все следующие команды эквивалентны:
Затем запустим программу, чтобы убедиться, что она работает. Для дополнительного удобства мы добавим каталог установки в наш PATH, чтобы упростить запуск двоичных файлов:
Пользователи Windows могут проконсультироваться в этом посте по установке %PATH%.
Если вы используете систему управления версиями, сейчас самое подходящее время для инициализации репозитория, добавления файлов и фиксации вашего первого изменения. Опять же, этот шаг не является обязательным: вам не нужно использовать систему управления версиями для написания кода Go.
Импорт пакетов из вашего модуля
Напишем пакет morestrings и воспользуемся им из программы hello. Сначала создайте каталог для пакета с именем $HOME/hello/morestrings, а затем файл с именем reverse.go в этом каталоге со следующим содержимым:
Поскольку наша функция ReverseRunes начинается с заглавной буквы, она экспортируется и может использоваться в других пакетах, которые импортируют наш пакет morestrings.
Давайте проверим, что пакет компилируется с помощью go build:
Это не приведет к созданию выходного файла. Вместо этого он сохраняет скомпилированный пакет в локальном кеше сборки.
Убедившись, что пакет morestrings собирается, давайте воспользуемся им из программы hello. Для этого измените исходный $HOME/hello/hello.go, чтобы использовать пакет morestrings:
Установите программу hello:
Импорт пакетов из удаленных модулей
Теперь, когда у вас есть зависимость от внешнего модуля, вам нужно загрузить этот модуль и записать его версию в файл go.mod.
Команда go mod tidy добавляет требования к отсутствующим модулям для импортированных пакетов и удаляет требования к модулям, которые больше не используются.
Зависимости модулей автоматически загружаются в подкаталог pkg/mod каталога, указанного переменной среды GOPATH. Загруженное содержимое для данной версии модуля совместно используется всеми другими модулями, которым требуется эта версия, поэтому команда go помечает эти файлы и каталоги как доступные только для чтения. Чтобы удалить все загруженные модули, вы можете передать флаг -modcache для очистки:
Тестирование
Go имеет легкий фреймворк тестирования, состоящую из команды go test и пакета testing.
Добавьте тест в пакет morestrings, создав файл $HOME/hello/morestrings/reverse_test.go, содержащий следующий код Go.
Затем запустите тест с помощью go test:
Что дальше
Чтобы ознакомиться с оcновами Go воспользуйтесь серией постов Основы Go.
Подборка Эффективный Go содержит советы по написанию понятного идиоматического Go кода.
Весь код в языке Go организуется в пакеты. Пакеты представляют удобную организацию разделения кода на отдельные части или модули. Модульность позволяет определять один раз пакет с нужной функциональностью и потом использовать его многкратно в различных программах.
Код пакета располагается в одном или нескольких файлах с расширением go . Для определения пакета применяется ключевое слово package . Например:
В данном случае пакет называется main . Определение пакета должно идти в начале файла.
Есть два типа пакетов: исполняемые (executable) и библиотеки (reusable). Для создания исполняемых файлов пакет должен иметь имя main . Все остальные пакеты не являются исполняемыми. При этом пакет main должен содержать функцию main , которая является входной точкой в приложение.
Импорт пакетов
Нередко программы подключают сразу несколько внешних пакетов. В этом случае можно последовательно импортировать каждый пакет:
В данном случае подключается встроенный пакет math, который содержит функцию Sqrt() , возвращающую квадратный корень числа.
Либо чтобы сократить определение импорта пакетов можно заключить все пакеты в скобки:
Пакет из нескольких файлов
Один пакет может состоять из нескольких файлов. Например, определим в папке два файла:
В файле factorial.go определим функцию для подсчета факториала:
Данный файл принадлежит пакету main.
В файле main.go используем функцию для вычисления факториала:
Данный файл также принадлежит пакету main. Файлов может и быть и больше. Теперь скомпилируем из этих файлов программу. Для этого перейдем в консоли к папке проекта и выполним команду:
Флаг -o указывает, как будет называться выходной файл - в данном случае main.exe. Затем идут все компилируемые файлы. После выполнения этой команды будет создан файл main.exe, который мы сможем запустить в консоли:
Файлы в разных пакетах
Теперь рассмотрим другую ситуацию, когда файлы нашей программы разделены по разным пакетам. Определим в папке проекта каталог computation . Затем в каталог computation добавим следующий файл factorial.go:
Код файла factorial.go принадлежит пакету computation. Важно отметить, что название функции начинается с заглавной буквы. Благодаря этому данная функция будет видна в других пакетах.
И чтобы использовать функцию factorial, надо импортировать этот пакет в файле main.go:
Путь "./computation" указывает, что пакет находится в папке computation.
Компиляция и выполнение программы осуществляется также как и ранее без необходимости указания всех файлов из других пакетов:
я использовал GOPATH но для этой текущей проблемы, с которой я сталкиваюсь, это не помогает. Я хочу иметь возможность создавать пакеты, специфичные для проекта:
Я пробовал несколько способов, но как мне получить package1.go для работы в binary1.go или binary2.go и так далее?
например; я хочу иметь возможность import "package1" и затем иметь возможность запускать go build binary1.go и все работает без ошибки, что пакет не может быть найден на GOROOT или GOPATH . Этот причина, по которой мне нужна такая функциональность, - для крупномасштабных проектов; я не хочу ссылаться на несколько других пакетов или хранить их в одном большом файле.
перейти управление зависимостями резюме:
- vgo если ваша версия go: x >= go 1.11
- dep или vendor если ваша версия go: go 1.6 >= x < go 1.11
- вручную, если ваша версия go: x < go 1.6
Edit 3: Go 1.11 имеет функцию vgo что будет заменить dep .
использовать vgo см. модули документация. TLDR ниже:
этот метод создает файл с именем go.mod в каталоге проектов. Затем вы можете создать свой проект с помощью go build . Если GO111MODULE=auto установлен, то ваш проект не может быть в $GOPATH .
Edit 2: Метод vendoring по-прежнему действителен и работает без проблем. vendor в основном ручной процесс, из-за этого dep и .
Edit 1: хотя мой старый способ работает, он больше не " правильный" способ сделать это. Вы должны использовать продавец возможности vgo или dep (на данный момент), которые включены по умолчанию в Go 1.6; посмотреть. Вы в основном добавляете свои" внешние "или" зависимые " пакеты в vendor каталог; после компиляции компилятор сначала будет использовать эти пакеты.
нашли. Я смог импортировать локальный пакет с GOPATH создать папку package1 а затем импорт с import "./package1" на binary1.go и binary2.go скрипты такие:
Итак, моя текущая структура каталогов выглядит так:
я должен также отметить, что относительные пути (по крайней мере в Go 1.5) также работают, например:
нет такой вещи, как "локальный пакет". Организация пакетов на диске ортогональна любым родительским/дочерним отношениям пакетов. Единственной реальной иерархией, формируемой пакетами, является дерево зависимостей, которое в общем случае не отражает дерево каталогов.
и не боритесь с системой сборки без веской причины. Сохранение десятка символов на импорт в любой нетривиальной программе не является хорошей причиной, потому что, например, проекты с относительными путями импорта не являются go-gettable.
понятие путей импорта имеет некоторые важные свойства:
- пути импорта могут быть глобально уникальными.
- в сочетании с GOPATH путь импорта можно однозначно перевести в путь к каталогу.
- любой путь к каталогу в GOPATH может быть однозначно переведен в путь импорта.
все вышеперечисленное разрушается с помощью относительных путей импорта. Не делай этого.
PS: в тестах компилятора Go есть несколько мест в устаревшем коде, которые используют относительный импорт. ATM, это единственная причина, по которой относительный импорт поддерживается вообще.
вы пытаетесь распределить свой пакет. Я предполагаю, что package1 и package2 являются, в некотором роде, частью одного и того же пакета, но для удобства чтения вы разделяете их на несколько файлов.
Если предыдущий случай был вашим, вы можете использовать одно и то же имя пакета в этих кратных файлах, и это будет похоже на тот же файл.
Я не эксперт Go, и это мой первый пост в StackOveflow, поэтому, если у вас есть совет, он будет хорошо принят.
чтобы Добавить "локальный" пакет в проект, добавьте папку (например, "package_name"). И поместите файлы реализации в эту папку.
в своем package main этого:
здесь package_name - это имя папки, и оно должно совпадать с именем пакета, используемым в файлах whatever_name1.пойти и whatever_name2.идти. Другими словами, все файлы с подкаталогом должны иметь один и тот же пакет.
вы можете дополнительно вложить больше подкаталогов, пока в импорте указывается весь путь к родительской папке.
Читайте также: