Где ресурсы должны храниться в golang

Question

В моем приложении используются файлы конфигурации json и другие ресурсы. Где я должен поместить их в свою иерархию проектов? я не мог найти ответ в http://golang.org/doc/code.html (Как написать код Go)

UPD: Вопрос не об автоматическом распределении ресурсов с применением, но гораздо проще: Где я должен держать свои ресурсы в иерархии проекта? Есть ли какое-то стандартное место, которое кто-то ожидает от них?

Answer 1

В настоящее время нет ни одного правильного ответа, ни каких-либо сильных соглашений, которые были приняты или не были применены никакими инструментами Go в это время.

Обычно я начинаю с предположения, что нужные мне файлы находятся в том же каталоге, в котором будет запущена программа. Например, предположим, что мне нужно conf.json для myprog.go; то оба эти файлы живут вместе в одной и той же директории, и она работает просто запустить что-то вроде

go build -o myprog && ./myprog 

Когда я разворачивать код, то myprog двоичную и conf.json живут вместе на сервере. Сценарий run/supervisor должен быть cd в этот каталог, а затем запустить программу.

Это также работает, когда у вас много ресурсов; например, если у вас есть веб-сервер с JS, CSS и изображениями, вы просто предполагаете, что они относятся к cwd в коде и разворачивают каталоги ресурсов вместе с бинарным сервером.

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

И, наконец, еще один подход - не иметь никаких файлов ресурсов. go-bindata - полезный инструмент, который я использовал для этой цели - он просто кодирует некоторые данные в виде байтов в исходный файл Go. Таким образом, все выпекается в ваш двоичный файл. Я думаю, что этот метод наиболее полезен, когда данные ресурса редко или никогда не меняются и довольно малы. (В противном случае вы собираетесь отправлять огромные двоичные файлы.) Один (глупый) пример того, когда я использовал go-bindata в прошлом, заключался в том, чтобы выпекать значок в действительно простой сервер, который иначе не требовал каких-либо дополнительные файлы, кроме бинарного сервера.