а по этому вопросу подскажете?

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

вы все стреляете?

да, я дуралей, не залил один из подпакетов в репозиторий, из-за этого go get его и пытался подтянуть

Здравствуйте. Есть вопрос по интеграции cobra  в существующий проект. У меня есть сервис, в котором есть главный main.go и какие-то ещё директории файлы. Всё хорошо собирается через go build. Теперь я хочу сделать консольную команду в проекте. Создаю в нём отдельную директорию cmd. Внутри делаю команду root.go (в ней же подключаю и инициирую приложение) и ту команду, что мне нужна, допустим resend.go Также создаю там свой main.go (но у него пакет не main, а cmd), в котором команду из root.go выполняю. Соответственно вопрос, как теперь скомпилировать такой бинарник? go build ничего не создаёт. Go run ругается на то, что пакет не main.

go install ./...

функция main() должна быть в пакете main

но пакетов main может быть в дереве больше одно - раз их импортировать никак

имя же файла - main.go - просто соглашение, на самом деле ни на что не влияет

любом имя файла в гоу - ни на что не влияет

потому что они сливаются в имя пакета (кроме спец случаев постфикса для OS)

и test

так что - утверждение не верно 🙂

ну что мы в дыру сейчас полезем? test тоже постфикс

Вроде заработало. Но меня смущает вот такая структура:
/cmd
|____resend.go (пакет cmd)
|____main.go (только для команд, пакет main)
|____root.go (пакет cmd)
main.go (основной файл приложения, пакет main)
Как-то можно это более осмысленно структурировать?

а что за ____?

Это вывод tree.

обычно папка cmd появлякется в одном из двух случаев

1. из нашего модуля собирается несколько бинарников
2. наш модуль - библиотечный, и бинарник в нем играет вспомогательную роль

в любом случае - в папке cmd обычно не содержится файлов, а толькл подпапки, по числу бинарников, каждая называется по имени того бинарника, код которого в ней

а как же третий путь?

у нас viper+cobra для субкоманд

на одном бинарнике

Я понял. Т.е. команды сложить в отдульную директорию, и основной main.go положить в другую. Получится, что есть основной бинарник, есть под команды. Все они лежат в cmd, у каждого свой main.go и свой пакет main.