В моем приложении используются файлы конфигурации json и другие ресурсы. Где я должен поместить их в свою иерархию проектов? Я не мог найти ответ в http://golang.org/doc/code.html (Как написать код перехода)
Upd: Вопрос не в автоматическом распределении ресурсов с приложением, а гораздо проще: где я должен хранить свои ресурсы в иерархии проектов? Есть ли какое-то стандартное место, которое кто-то ожидает от них?
В настоящий момент нет ни одного правильного ответа, ни каких-либо сильных соглашений, принятых или принудительных с помощью любого инструмента Go.
Обычно я начинаю с предположения, что нужные мне файлы находятся в том же каталоге, в котором будет запущена программа. Например, предположим, что мне нужно conf.json для myprog.go; то оба этих файла живут вместе в одном каталоге, и он работает только для запуска чего-то вроде
go build -o myprog && ./myprog
Когда я развертываю код, двоичные файлы myprog и conf.json живут вместе на сервере. Запуск/супервизор script должен cd в этот каталог, а затем запустить программу.
Это также работает, когда у вас много ресурсов; например, если у вас есть веб-сервер с JS, CSS и изображениями, вы просто предполагаете, что они относятся к cwd в коде и развертывают каталоги ресурсов вместе с бинарным сервером.
Другой альтернативой принятию cwd является наличие флага -conf, который пользователь может использовать для указания файла конфигурации. Обычно я использую это для распространения инструментов командной строки и приложений с открытым исходным кодом, для которых требуется один файл конфигурации. Вы даже можете использовать флаг -assets или что-то, чтобы указать на все дерево файлов ресурсов, если хотите.
Наконец, еще один подход - не иметь никаких файлов ресурсов. go-bindata - полезный инструмент, который я использовал для этой цели - он просто кодирует некоторые данные в виде байтов в исходный файл Go. Таким образом, все это запекло в вашем двоичном коде. Я думаю, что этот метод наиболее полезен, когда данные ресурса редко или никогда не меняются и довольно малы. (В противном случае вы собираетесь отправлять огромные двоичные файлы.) Один (глупый) пример того, когда я использовал go-bindata в прошлом, заключался в том, чтобы выпекать значок в действительно простой сервер, который иначе не требовал каких-либо дополнительные файлы, кроме бинарного сервера.