Ответ 1
В настоящий момент нет ни одного правильного ответа, ни каких-либо сильных соглашений, принятых или принудительных с помощью любого инструмента 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 в прошлом, заключался в том, чтобы выпекать значок в действительно простой сервер, который иначе не требовал каких-либо дополнительные файлы, кроме бинарного сервера.